Re: Types on the right or on the left
| From: | Levi Morrison | Date: | Wed, 05 Nov 2014 01:06:31 +0000 |
| Subject: | Re: Types on the right or on the left | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-78695@lists.php.net to get a copy of this message | ||
On Tue, Nov 4, 2014 at 5:55 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> On 11/04/2014 04:42 PM, Levi Morrison wrote:
>>>> If we used this syntax instead, which wouldn’t disrupt grep:
>>>>
>>>> public Foo function bar();
>>>>
>>>> It’d be inconsistent with normal function declarations which would have to have
>>>> Foo after function.
>>>
>>> I don't understand that inconsistency.
>>>
>>> public Foo function bar() { }
>>>
>>> looks perfectly sane to me. PHP's syntax was very heavily influenced by
>>> C from day 1. In C you have:
>>>
>>> static int bar() { }
>>>
>>> In PHP the 'function' keyword indicates what follows is a function.
>>> Putting something in between the function keyword and the name of the
>>> function would confuse me. To me "function bar()" is inseparable and is
>>> equivalent to "bar()" in C which makes the above examples consistent
>>> with each other.
>>
>> Except
static function() and static
>> function foo() already have
>> meaning, and if we allowed static return types (very possible) that
>> would be ambiguous. This syntax is a no-go.
>
> static isn't a type it is a scope. You want to expand return types to
> also cover scopes? How is that in any way useful?
Basically because the return type would depend on the scope that
called it. This is done in production, for better or worse, already:
class A {
public static function make() {
return new static();
}
}
class B extends A {}
var_dump(B::make());
//object(B)#1 (0) {
//}
People have been asking for support; it's just out of the scope of this RFC..