To play devil's advocate a bit: It's a special case. If it was really an undefined method then this is suddenly ambiguous: $foo = new Foo();
If __construct() is undefined, what is being called in that case? By the same logic, that should throw an error as well. On the other hand, if __construct is presumed to be implicitly defined then I think it makes logical sense for parent::__construct() to always succeed. Side note: If __construct is implicit then __destruct should also be. On Mon, May 16, 2011 at 3:10 PM, Anthony Ferrara <ircmax...@gmail.com>wrote: > 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 <andrewcuri...@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 <johan...@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 > >> > >> > > > -- Andrew Curioso