Hi Zeev,

On 21.02.15 18:22, Zeev Suraski wrote:
> I’ve been working with François and several other people from internals@
> and the PHP community to create a single-mode Scalar Type Hints proposal.
> 
> I think it’s the RFC is a bit premature and could benefit from a bit more
> time, but given the time pressure, as well as the fact that a not fully
> compatible subset of that RFC was published and has people already
> discussing it, it made the most sense to publish it sooner rather than
> later.
> 
> http://wiki.php.net/rfc/coercive_sth

Thanks for the refreshed approach. Although there are already oh-so-many
RFCs and discussion, I found the sum up to be very clear. Thanks to you
at al.


1) About impact / BC

There's one thing I never understood, even not for 0.3 which almost went
through: why have this impact on internal
function/zend_parse_parameters/ZPP at all?

Why not just keep this strictly user-land /for now/ ?

The user-land change is much more controllable. The internal function
change is ... not sure how to say. Has such a big impact and I'm not
sure what should be the gain at all here.


2) I'm with Pierre regarding accepting e.g. 42.0 for an int. Just
imagine you pass the result of a calculation which happens to be a
result with a clean .0 fractional part and everything works. The next
time you calculate with a different input and *boom* your value is 42.1
and thus reject. That's quite a POLA [1] right there.



I know I will derail this whole thing when I write the next point but I
really think one of the best ways to move forward is to
- only support strict types, e.g. function foo(string $bar)
- in user-land code

That way the there's almost no BC impact sans the possible clashes of
classnames (which I probably just missed how this will be resolved?).


Future RFCs could still reason about other typo of hints (initial weak
STH or now this coercive STH) and expand on the syntax.



thanks,
- Markus

[1] http://en.wikipedia.org/wiki/Principle_of_least_astonishment

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to