On Wed, Jul 10, 2013 at 8:30 PM, Sara Golemon <poll...@php.net> wrote:
>> With regard to any sort of hinting, an issue of 'one of' return types
>> would need to be addressed (I hope).
>>
>> function foo(SomeClass $bar, int $baz) : bool, SomeClass {}
>>
>> Allowing for a failure (False) or a success (SomeClass).
>>
>> We (HHVM) deal with failure alternates by way of a "nullable" syntax:
>
> function foo(SomeClass $bar, int $baz) : ?SomeClass {}
>
> Means the function returns SomeClass or null. null being the "failure"
> case.
>
> We also do "mixed" for anything (basically, no type hint, but explicitly
> stated), and "numeric" for a less aggressive float/int/numeric-string
> (though that's more specific to arg types than return types).
>
>
>
>>
>> I think it would useful to have a Null hint (like C's void I suppose).
>> More to do with explicitly saying no return type, rather than saying
>> nothing which means an undefined return type.
>>
>> function foo(SomeClass $bar, scalar $baz) {} /** you can return
>> something, but who knows what will happen with it. **/
>> vs
>> function foo(SomeClass $bar, scalar $baz) : Null {} /** This method does
>> not return anything and to do so would be wrong. **/
>>
>>
> function foo() : void {} is our syntax. A null return value is an actual
> thing (a null thing), whereas no return is more explicit. I know that
> `return;` gets translated into `return null;` anyway, but we also look at
> the caller side (return_value_used) and warn about "attempt to use value
> from a function returning void" like C/C++ do.
>
>
> Another advantage of scalar is the ability to stop scalar only functions
>> from receiving objects, arrays, etc.. Currently no way to inhibit that
>> without type testing in the function.
>>
>> We don't currently do "any scalar", though we do have "numeric" (as
> mentioned above). I agree with you that "scalar" would be a nice meta-type.
>
>
>
>> And, if PHP evolves to allow for __toScalar(), then an object can
>> represent itself as a scalar for those situations where the scalar type
>> hint is required. I think this may be a bit much initially though (unless
>> some clever bod has already worked all this out). Being able to cast an
>> instance from type A to type B via __autocast_XXXX where XXXX is the
>> resultant type ... ha ha ... OK that really is just pushing things. Maybe.
>>
>> Going off-topic here, but I worry that __toScalar() would collide in a
> messy way with __toString() (and other, future __toXXXX() behavior). Not
> severely against it, mind you, but I think we (PHP) need to be cautious
> about going down that road.
>
> -Sara
>
> P.S. - Your reply only went to me, but I assume you wanted to include
> internals@ so I put them back in the To: line.
Thanks for your input Sara, everything sounds very interesting. In all
fairness I haven't looked at HHVM but I from what you described about
this particular feature sounds good.
Should I conclude that there's enough interest for this feature and
move from a gist to a RFC? If so, I would definitely need someone to
help out with the implementation.
Best regards,
Florin
----
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
