Hey all,
Was there any more discussion on this? I've been bit by this as well,
several times over the past 3 years.
I'd opt for option (d) for all prototype/signature checking. Here's why:
I don't think the return "type" should be considered part of the
signature when enforcing LSP. PHP (currently), does not care what the
type of the return value is, much less if there is even one to be
returned. Whether or not it is a reference or a value should not impact
the conditions presented to the caller, in other words "the
preconditions are not strengthened in a subtype." Since PHP does no
enforcement of return values, postconditions don't seem to apply.
Also, relaxing the checks would be backwards compatible. Since no code
should currently exist that does this (its an E_FATAL currently if the
signature originates in an interface, E_STRICT notice when the signature
originates in an abstract/base class overridden in a subclass).
Thoughts?
Ralph Schindler
Johannes Schlüter wrote:
Hi,
On Tue, 2010-04-27 at 10:17 +0200, Etienne Kneuss wrote:
it looks like the fact that ArrayAccess::offsetGet is not returning a
reference is a recurrent problem, I see basically 4 options:
The main use case is some nested structure like
$o = new ArrayObject();
/*...*/
$o[23][42] = "foobar";
right?
a) Ignore the issue, change nothing
b) Rewrite offsetGet to return a ref, breaking BC
c) Create a new ArrayAccess interface where it does return a ref
d) Relax prototype checks so that both are allowed.
If the above case is correct and due to me not liking references I
wonder whether there is a way to for an option e) which adds support for
this in some way to the engine.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
