Re: [RFC] Return Type Declarations pre-vote follow-up

From: Date: Sat, 10 May 2014 09:06:52 +0000
Subject: Re: [RFC] Return Type Declarations pre-vote follow-up
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
Hello,

2014-05-09 23:32 GMT+02:00 Josh Watzman <[email protected]>:

> > I'm not sure it is a good idea. This means having this code:
> > class FooGetter {
> >  function getFoo(): Foo { return new Foo(); }
> > }
> >
> > I can extend it as:
> > class TwoFaceFooGetter extends FooGetter {
> >  function getFoo() { return rand()%2?new Bar():new Foo(); }
> > }
> >
> > and every function getting FooGetter and expecting getFoo() to return
> > Foo is now broken since instead it could just get Bar(). Since the type
> > return specification is meant, as far as I understand, exactly to avoid
> > cases like that, I don't see it as a good idea.
>
> I understand, and this is the same argument LeviM has been making. (We
> just discussed on IRC in #hhvm extensively.)
>
> Our view is that this code was *already* wrong. The type annotations don't
> make it more or less wrong. What they do let you do is enforce, once the
> annotation is in place, that it's correct moving forward for the places
> that are annotated. (And if you want to go fix up and annotate
> TwoFaceFooGetter, go do that! Or if you don't right now, don't!) Doing it
> this way also means that you don't have to convert your entire hierarchy
> all at once -- gradual conversion of existing code was an important feature
> when we were adding the Hack type system onto PHP.
>
> > The type 'self' is not late bound, unlike 'static' and exists in the
> language elsewhere; I am not introducing a new keyword 'self' in this RFC..
>
> We discussed this on IRC and came to consensus that "self" is just fine,
> though not necessarily terribly useful if you think further than just
> enforcing the return type, to how that information might be propagated and
> used at the callsite -- for example by the Hack static typechecker, or even
> by a human. The type "static" tends to be what you want. But this isn't a
> huge deal -- "self" as proposed isn't *wrong*.
>
>
As far as I understand, the keyword "self" was just inherited from argument
type hinting. The keyword "static" is not used there, so it was not carried
over.

Maybe "static" should be introduced to both cases, but in a separate RFC.



Lazare INEPOLOGLOU
Ingénieur Logiciel


Thread (15 messages)

« previous php.internals (#74114) next »