hi Stanislav , Marcus, On Sat, Aug 9, 2008 at 1:00 AM, Marcus Boerger <[EMAIL PROTECTED]> wrote: > Hello Stanislav, > > Saturday, August 9, 2008, 12:40:34 AM, you wrote: > >> Hi! > >>> Yes, it breaks the principle. E.g. caller knows callee returns by ref - you >>> break this, as easy as that. > >> I'm sorry I think you misunderstood my proposal. I proposed allowing >> overriding this: >> public function __get($name) >> with this: >> public function &__get($name) > >> but not the reverse. So if the caller known callee returns by ref - it >> means it already expects the child class, not the parent class. Thus, it >> does not break anything. >> Is there any other problem that you see? > > What makes you think there won't be a problem with the reverse. The caller > does not expect a reference but the calle returns one? In OOP the return > value of the derived class' method must be an instance of the class defined > by the base class' method or a subclasse of that. And so far we tream them > different, rather than a reference is a subclass of a normal value or vice > versa.
I know that we don't like to add new magic methods, but this case seems to require new ones. What's about __getByRef (and its setter equivalent if it is also not supported yet)? Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
