# by-ref return & inheritance - Thread: https://externals.io/message/39773 - Original archive: https://news-web.php.net/php.internals/39773 - Started by Stanislav Malyshev on 2008-08-08T20:32:53+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #39773 — Stanislav Malyshev — 2008-08-08T20:32:53+00:00 URL: https://externals.io/message/39773#39773 Hi! Right now, strict inheritance rules do not allow to override public function __get($name) with public function & __get($name) I think we may want to allow this (but not the reverse - overriding by-ref return with by-val should not be allowed). Since by-ref return still can be used in by-val context, it should not break the LSP. And it can be useful in some situations - __get having specific by-ref semantics is one of them. What do you think? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #39779 — Marcus Boerger — 2008-08-08T22:05:21+00:00 URL: https://externals.io/message/39773#39779 · In reply to: #39773 Hello Stanislav, I think we may want to stick to our is-a mantra. marcus Friday, August 8, 2008, 10:32:53 PM, you wrote: > Hi! > Right now, strict inheritance rules do not allow to override > public function __get($name) > with > public function & __get($name) > I think we may want to allow this (but not the reverse - overriding > by-ref return with by-val should not be allowed). Since by-ref return > still can be used in by-val context, it should not break the LSP. And it > can be useful in some situations - __get having specific by-ref > semantics is one of them. > What do you think? > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com http://www.zend.com/ > (408)253-8829 MSN: stas@zend.com Best regards, Marcus --- ## #39780 — Stanislav Malyshev — 2008-08-08T22:16:29+00:00 URL: https://externals.io/message/39773#39780 · In reply to: #39779 Hi! > I think we may want to stick to our is-a mantra. I'm not sure I understand what you mean here. But our principle was to allow things that do not violate the LSP - such as adding optional parameters, for example. I think returning by-ref can be allowed on the same principle. Is there any problem with allowing it that you see? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #39781 — Marcus Boerger — 2008-08-08T22:27:25+00:00 URL: https://externals.io/message/39773#39781 · In reply to: #39780 Hello Stanislav, Saturday, August 9, 2008, 12:16:29 AM, you wrote: > Hi! > > […] > I'm not sure I understand what you mean here. But our principle was to > allow things that do not violate the LSP - such as adding optional > parameters, for example. I think returning by-ref can be allowed on the > same principle. Is there any problem with allowing it that you see? Yes, it breaks the principle. E.g. caller knows callee returns by ref - you break this, as easy as that. Best regards, Marcus --- ## #39783 — Stanislav Malyshev — 2008-08-08T22:40:34+00:00 URL: https://externals.io/message/39773#39783 · In reply to: #39781 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? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #39784 — Marcus Boerger — 2008-08-08T23:00:08+00:00 URL: https://externals.io/message/39773#39784 · In reply to: #39783 Hello Stanislav, Saturday, August 9, 2008, 12:40:34 AM, you wrote: > Hi! > > […] > 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. Best regards, Marcus --- ## #39785 — Pierre Joye — 2008-08-08T23:47:19+00:00 URL: https://externals.io/message/39773#39785 · In reply to: #39784 hi Stanislav , Marcus, > Hello Stanislav, > > Saturday, August 9, 2008, 12:40:34 AM, you wrote: > > > […] > > > […] > > > […] > > > […] > > 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 --- ## #39786 — Stanislav Malyshev — 2008-08-08T23:48:41+00:00 URL: https://externals.io/message/39773#39786 · In reply to: #39784 Hi! > 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 Well, I don't know any case where $a = foo() would work in a substantially different way for the user if foo() returns by-ref and not by-val. If you are aware of any such case - please tell, that's exactly why I ask. > 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. Err... I'm afraid I don't understand what you mean here. By-ref return is not a subclass of anything - not only PHP has no type control of return values, by-ref is a zval flag and not a type - so I don't think there are any subclasses here per se. What is relevant that value returned by-ref can be used in by-val context. The question is very simple - can you (or anybody else) think of any scenario that such override would lead to any problem LSP-wise? Any code that wouldn't work with such override? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #39787 — Stanislav Malyshev — 2008-08-08T23:50:33+00:00 URL: https://externals.io/message/39773#39787 · In reply to: #39785 Hi! > 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)? Why would we need that? We already have perfectly good __get, which can perfectly return by-ref. The question is only if we allow override __get that was declared by-val with __get that is declared by-ref. As for __set, __set doesn't return anything at all, so it's not very relevant anyway. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #39788 — Pierre Joye — 2008-08-08T23:59:10+00:00 URL: https://externals.io/message/39773#39788 · In reply to: #39787 hi! > Hi! > > > […] > > Why would we need that? We already have perfectly good __get, which can > perfectly return by-ref. The question is only if we allow override __get > that was declared by-val with __get that is declared by-ref. I'm not sure to like the idea. I'm not a fan of OO strictness but I'd to agree with Marcus, I do not expect a reference from an overrided __get. There is also the problem with internal classes, if I'm not mistaken. > As for __set, __set doesn't return anything at all, so it's not very > relevant anyway. I meant set by reference. Is it not the same problem? class foo {function __set($key, &$value) {}} >> fatal error Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #39789 — Stanislav Malyshev — 2008-08-09T00:09:50+00:00 URL: https://externals.io/message/39773#39789 · In reply to: #39788 Hi! > I'm not sure to like the idea. I'm not a fan of OO strictness but I'd > to agree with Marcus, I do not expect a reference from an overrided How can you "not expect reference"? I.e. which code that worked previously wouldn't work now? > __get. There is also the problem with internal classes, if I'm not > mistaken. Which problem? Could you elaborate? > I meant set by reference. Is it not the same problem? > > class foo {function __set($key, &$value) {}} >> fatal error Ah, I see what you mean. But I'm not sure __set has this semantics now anyway - unless we'd support it with $a->foo =& $bar somehow, but right now we don't. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com