Well, if we follow that logic (which does make sense), then shouldn't all magic methods be implicit? So parent::__sleep/__call/__get/etc would silently do the default if not defined?
On Mon, May 16, 2011 at 3:18 PM, Andrew Curioso <andrewcuri...@gmail.com> wrote: > 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
