On Dec 22, 2011, at 7:21 PM, Ángel González wrote:
> On 23/12/11 00:08, Will Fitch wrote:
>> Sent from my iPad
>> On Dec 22, 2011, at 5:51 PM, "Ángel González" <keis...@gmail.com> wrote:
>>
>>> Your examples only show class methods with visibility qualifyiers, and
>>> looking at the changes to zend_language_parser.y
>>> it seems as if would only be available for methods. Wouldn't return
>>> hints be available for plain functions?
>> Right now, it's only available for methods. Personally, I'm not a fan
>> of return types for functions. Adding this for functions in its form
>> today will also introduce shift/reduce issues.
> Yes, it's much easier for the parser for methods with explicit
> visibility (note that public is optional).
> I'm ok on requiring the public for methods with a return hint, but if
> methods can get return hints,
> normal functions must, too.
>
> If it's hard with your proposed syntax, it should be discarded and a
> better one developed.
> Else we would end up with different syntaxes for return hints depending
> on the kind of function.
It's not a matter of being difficult. I can see your argument, however.
>
>
> For instance, the return hint could go at the end of the prototype:
>
> function foo (Class1 $a, Class2 $b) => Class3 {
> return new Class3($a, $b);
> }
>
> (I'm unsure about the T_DOUBLE_ARROW, although for parsing, I feel there
> should be some token there
> before the class name, though I'm unconvinced on which)
Let me see what can be done without doing too much to the definitions. I like
the idea of not making "function" required.
>
>
>>> In functional programming, it is common to return nullable types:
>>> returns an instance of class Foo or null, an array or false, etc.
>>>
>>> This is supported in normal arguments with the "= null" hint, and I
>>> think there should be something equivalent for return types.
>>> Does the proposed implementation allow null everywhere? (there's an
>>> example of returning null from a return hint of array)
>>> That seems wrong to me. Unless there's a way to make it strict (eg.
>>> array! for only arrays).
>> Most modern languages allow returning null in any case. This is a hail
>> Mary in the event something happens, but throwing an exception is
>> inappropriate. I see no reason to diverge from that.
> I disagree with you, but Stas already provided a compelling case.
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
