I prefer option (3) - invariant return types.
Actually, return type compatibility check should follow all the rules for
parameter type compatibility check (may be even reuse or share the code).
This solution may be implemented efficiently and consistently.
It also must be enough for 99% use cases.
On 28 Nov 2014, at 09:31, Dmitry Stogov dmi...@zend.com wrote:
I prefer option (3) - invariant return types.
Actually, return type compatibility check should follow all the rules for
parameter type compatibility check (may be even reuse or share the code).
No, it shouldn't match
Andrea Faulds wrote on 28/11/2014 10:57:
On 28 Nov 2014, at 09:31, Dmitry Stogov dmi...@zend.com wrote:
I prefer option (3) - invariant return types.
Actually, return type compatibility check should follow all the rules for
parameter type compatibility check (may be even reuse or share the
I didn't get what you mean.
parameters are invariant, invariance, which is safe for both and it
shouldn't match parameters are contradictory.
Thanks. Dmitry.
On Fri, Nov 28, 2014 at 1:57 PM, Andrea Faulds a...@ajf.me wrote:
On 28 Nov 2014, at 09:31, Dmitry Stogov dmi...@zend.com wrote:
On 28 Nov 2014, at 12:27, Dmitry Stogov dmi...@zend.com wrote:
I didn't get what you mean.
parameters are invariant, invariance, which is safe for both and it
shouldn't match parameters are contradictory.
Well, that’s why I said “the exception is invariance”.
--
Andrea Faulds
I prefer option (3) - invariant return types.
Actually, return type compatibility check should follow all the rules for
parameter type compatibility check (may be even reuse or share the code).
Realistically there isn't much code to share, especially since the two
structures are incompatible.
Hi Levi,
if you remember, in my patch return_type was actually stored in
arg_info[-1].
it was mainly done for unification and to allow return type hinting for
internal functions (they already use arg_info[-1])
So the strictures may be compatible.
See
Lazare Inepologlou wrote on 26/11/2014 10:21:
* Parameter types are contravariant, otherwise they are not type sound.
Yet, contravariance in general is of little interest (I cannot think of any
practical example), so invariance is a good compromise.
After reading the Wikipedia article, I've
Levi Morrison wrote on 25/11/2014 17:08:
1. Do covariant return types; check them at definition time
2. Do covariant return types; check them at runtime
3. Do invariant return types; check them at definition time
I guess there's also option 4 - do weak invariance, as we do with
On Tue, Nov 25, 2014 at 11:42 PM, Nikita Popov nikita@gmail.com wrote:
On Tue, Nov 25, 2014 at 11:13 PM, Marc Bennewitz dev@mabe.berlin wrote:
Am 25.11.2014 um 22:43 schrieb Levi Morrison:
On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz dev@mabe.berlin wrote:
I think it's required to
2014-11-25 23:42 GMT+01:00 Nikita Popov nikita@gmail.com:
On Tue, Nov 25, 2014 at 11:13 PM, Marc Bennewitz dev@mabe.berlin wrote:
Am 25.11.2014 um 22:43 schrieb Levi Morrison:
On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz dev@mabe.berlin
wrote:
I think it's required to do
On 26 November 2014 10:21:12 GMT, Lazare Inepologlou linep...@gmail.com wrote:
http://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)#Covariant_method_return_type
Can I just recommend that everyone interested in this discussion read that
whole article (at least until it
Hi!
class FooFactory {
function create(Foo $foo): Foo { return $foo; }
}
class GooFactory extends FooFactory {
function create(Goo $goo): Goo { return $goo; }
}
OK HHVM allows it - we also allow it but trigger an E_STRICT error
@see http://3v4l.org/UhtOb
This is because this
Hi!
I've also used it because it can adequately show the differences in how each
of the following options work:
1. Do covariant return types; check them at definition time
2. Do covariant return types; check them at runtime
3. Do invariant return types; check them at definition time
Dear Internals,
As you may remember, I closed the voting on the return types
[RFC](https://wiki.php.net/rfc/returntypehinting) because of a design
flaw that was found during the voting process. The purpose of this
discussion thread is to explain the various options for checking
return type
-Ursprüngliche Nachricht-
Von: morrison.l...@gmail.com [mailto:morrison.l...@gmail.com] Im Auftrag von
Levi Morrison
Gesendet: Dienstag, 25. November 2014 18:09
An: internals
Betreff: [PHP-DEV] [RFC][Discussion] Return Type Variance Checking
Dear Internals,
As you may remember
It should be mentioned for Option 3 that covariant return types are not
supported just at the definition level . Even with invariant return types the
following is perfectly fine:
class A {
function foo(): B { return new B; }
}
class B extends A {
function foo(): B { return new C; }
I think it's required to do the type check on runtime (Option 2) because
one of the use cases for return type-hint are factories and such often do
instantiation in base of unknown string values:
class MyFactory {
public static function factory($name) : AdapterInterface {
$class =
On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz dev@mabe.berlin wrote:
I think it's required to do the type check on runtime (Option 2) because
one of the use cases for return type-hint are factories and such often do
instantiation in base of unknown string values:
class MyFactory {
Am 25.11.2014 um 22:43 schrieb Levi Morrison:
On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz dev@mabe.berlin wrote:
I think it's required to do the type check on runtime (Option 2) because
one of the use cases for return type-hint are factories and such often do
instantiation in base of
Am 25.11.2014 um 23:13 schrieb Marc Bennewitz:
Am 25.11.2014 um 22:43 schrieb Levi Morrison:
On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz dev@mabe.berlin wrote:
I think it's required to do the type check on runtime (Option 2)
because
one of the use cases for return type-hint are factories
On Tue, Nov 25, 2014 at 11:13 PM, Marc Bennewitz dev@mabe.berlin wrote:
Am 25.11.2014 um 22:43 schrieb Levi Morrison:
On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz dev@mabe.berlin wrote:
I think it's required to do the type check on runtime (Option 2) because
one of the use cases for
22 matches
Mail list logo
