Re: Inconsistencies with constructors in SPL

Personally, I really don't care for something like this. Would it be caught by a __call declaration if one existed (since it is a call to an undefined method)? Would you expect it to? I'd rather see calls to non-existent methods generate a catachable fatal error (rather than a hard fatal error that's currently thrown). That way we can use an error exception to "catch" the fatal and recover from it if necessary. But silently ignoring a called function, something just doesn't sit right about that... On Mon, May 16, 2011 at 2:44 PM, Andrew Curioso <andrewcurioso@gmail.com> wrote: > I like that idea and I like that it works for userland classes as well. > > +1 > > Do you think it should throw a warning, notice, or -- as you both suggested > -- just silently succeed? > > > > > 2011/5/16 Johannes Schlüter <johannes@schlueters.de> > >> Hi, >> >> I|d actuallz suggest a different option: >> >> If a parent constructor is called but doesn't exist the engine should >> ignore this. The same goes for destructors. >> >> This solution would also work for userland classes. >> >> johannes >> >> On Mon, 2011-05-16 at 14:14 -0400, Andrew Curioso wrote: >> > So, I ran across bug #54631 >> > >> > A fatal error is thrown if you try to call parent::__construct() from a >> > subclass >> > of SplObjectStorage. >> > >> > I was going to close it as "expected behavior" since that is pretty >> normal >> > if the parent class doesn't implement __construct(). >> > Also, the docs don't list it as having a __construct() method. >> > >> > But then look at SplDoublyLinkedList (and a bunch of others). They are >> > documented >> > as having a __construct() method, yet it triggers a fatal error when you >> try >> > to call >> > "parent::__construct()" from a subclass' constructor . >> > >> > So it seems to me that there are two possible solutions: >> > >> > - Update the docs to remove ::__construct() for classes that don't have >> one. >> > - Make sure __construct() is implemented in all SPL classes * and update >> the >> > docs. >> > >> > * Even if it is empty. >> > >> > What's everyone thinking? >> > >> > I'd be more than happy to add the constructors to the code where needed, >> I >> > just >> > want to make sure that it is the right move first. >> > >> > >> > - Andrew >> >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >