Re: [RFC] Return Type Declarations pre-vote follow-up
Hello,
2014-05-12 2:53 GMT+02:00 Larry Garfield <[email protected]>:
> On 05/09/2014 05:03 PM, Stas Malyshev wrote:
>
>> 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.
>>
>
> I'm inclined to agree with Stas and and Levi here. If we want
> return-type-suggestions, that already exists in docblocks and any
> self-respecting IDE already takes advantage of that. If I use an actual
> return type, it means I *want* any such broken code to fatal and die (just
> as it would for a parameter type "hint"). That's how I know it's Doing It
> Wrong(tm) so I can fix it. If that means I can't actually commit the
> return type code until I fix the other code, so be it. That's my incentive
> to fix the already broken code. :-)
>
>
Docblocks is not the solution. If you want to take profit of static
analysis without the penalty of runtime type checking, Hack has shown the
way with its "soft type hints".
Lazare INEPOLOGLOU
Ingénieur Logiciel
Thread (15 messages)