On Tue, Nov 4, 2014 at 5:55 PM, Rasmus Lerdorf <ras...@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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
