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 https://gist.github.com/dstogov/8deb8b17e41c1a5
> 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
> On 28 Nov 2014, at 12:27, Dmitry Stogov 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
http://ajf.me/
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 wrote:
>
> > On 28 Nov 2014, at 09:31, Dmitry Stogov wrote:
> >
> > I prefer option
Andrea Faulds wrote on 28/11/2014 10:57:
On 28 Nov 2014, at 09:31, Dmitry Stogov 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 shoul
> On 28 Nov 2014, at 09:31, Dmitry Stogov 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 parameters, that'd br
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.
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
para
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 bee
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 b
On 26 November 2014 10:21:12 GMT, Lazare Inepologlou 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 gets into the guts o
2014-11-25 23:42 GMT+01:00 Nikita Popov :
> On Tue, Nov 25, 2014 at 11:13 PM, Marc Bennewitz wrote:
>
> >
> > Am 25.11.2014 um 22:43 schrieb Levi Morrison:
> >
> > On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz
> wrote:
> >>
> >>> I think it's required to do the type check on runtime (Option 2
On Tue, Nov 25, 2014 at 11:42 PM, Nikita Popov wrote:
> On Tue, Nov 25, 2014 at 11:13 PM, Marc Bennewitz wrote:
>
>>
>> Am 25.11.2014 um 22:43 schrieb Levi Morrison:
>>
>> On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz wrote:
>>>
I think it's required to do the type check on runtime (Opti
On Tue, Nov 25, 2014 at 11:13 PM, Marc Bennewitz wrote:
>
> Am 25.11.2014 um 22:43 schrieb Levi Morrison:
>
> On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz 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
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 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
Am 25.11.2014 um 22:43 schrieb Levi Morrison:
On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz 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
On Tue, Nov 25, 2014 at 2:07 PM, Marc Bennewitz 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 {
> public static
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 = 'MyN
> 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 n
19 matches
Mail list logo
