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
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
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
Hello Stanislav,
Saturday, August 9, 2008, 12:16:29 AM, you wrote:
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?
Yes, it breaks the principle. E.g. caller knows callee returns by ref - you
break this, as easy as that.
Best regards,
Marcus
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
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.
Best regards,
Marcus
hi Stanislav , Marcus,
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
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
hi!
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.
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
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
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