Re: ArrayAccess::offsetGet not returning a ref

From: Date: Sat, 07 Aug 2010 03:25:38 +0000
Subject: Re: ArrayAccess::offsetGet not returning a ref
References: 1 2 3 4 5 6 7 8 9  Groups: php.internals 
Request: Send a blank email to internals+get-49221@lists.php.net to get a copy of this message
On Sat, 07 Aug 2010 03:55:25 +0100, Etienne Kneuss <etienne@immomigsa.ch> wrote:
Returning a ref is an additional constraint, meaning that it would actually be covariance, and not contravariance. But yes, it makes sense.
Yes, you are right. To put it another way: a subclass should be able to * Relax the preconditions * Strengthen the post-conditions I actually noticed this shortly after sending the e-mail, but hoped no one else would :p
Actually, after rereading what you said and the proposed diff, I'm not sure it makes sense. It should _not_ be consistent with arguments. A method subtype may relax the parent prototype by not requiring a ref for an argument. This is fine and it's indeed contra-variant.
Again, my mistake. The if before was indeed about arguments...
However, the return value of a method subtype should be able to return a ref even if the parent prototype doesnt. However, if the parent requires a ref, the child should too. Which is covariant.
I'm confused, this was what exactly what I suggested. The condition I suggested is this (proto is the parent, fe the child): if (proto->common.return_reference && !fe->common.return_reference) { return 0; } So it returns an error condition if the parent returns a reference and the child doesn't. It's the check on the arguments that's wrong in this sense. However, I think invariance should be required here. The thing is, passing an argument by reference is actually also a post-condition -- if we pass an argument by reference, we're going to do something with it. In fact, invariance is required for the non-"rest" part of the arguments: if (fe->common.arg_info[i].pass_by_reference != proto->common.arg_info[i].pass_by_reference) { Again, sorry for the confusion. -- Gustavo Lopes

« previous php.internals (#49221) next »