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

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.

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 behavior you are proposing is good for migration and adoption, but what
then? What about the years afterwards where you now have this ability to
break the return type? It's much harder to remove this behavior than it is
to add it in later.

Hi!

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,

Of course it is wrong. The whole point of having strict typing is to
catch wrong code. If everybody would write only right code, we wouldn't
need any type checks - everything would be ok anyway (not correct for
some compiled languages as there types also tell the compiler how to
convert values to bits, but true for languages like PHP).

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

The whole point is that it won't be correct. In your model, when you use
typed function, essentially you know nothing about its return type, as
somebody could have overridden it with function returning anything. So
the only thing typing is useful for in your model is to document our
wishes about types. We already have that with @returns.

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.

My opinion is that we should not add features that do not make sense
conceptually. I have my issues with strict typing in php in general,
which I voiced at length here on the list already, but at least I can
see some internal logic in the concept, even though I still think it's
not the best fit for dynamic languages (neither Python nor Ruby nor
Javascript, to take three most popular ones, have it). But at least,
repeating, internal logic of knowing the variable type past the check is
there. What you are proposing is essentially documentation-only - you
can never know when you call a method what you are actually getting,
unless you explicitly check the object type for exact match (which
current strict typing syntax doesn't even allow). This is lacking even
internal logic, so I don't see how it makes sense to have such concept
in PHP.

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.

That depends on the method - I can see cases for both. Consider this:
class Toy {
static function ToyFactory($toy_class): self {
return new $toy_class;
}}
The one with static would have different semantics than the one with self.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Hello,

2014-05-09 23:32 GMT+02:00 Josh Watzman jwatzman@fb.com:

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