On 02/16/2015 05:57 PM, Sara Golemon wrote: > On Mon, Feb 16, 2015 at 4:52 PM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: >> I still disagree strongly that it serves everyone's needs. The internal >> API and APIs provided by extensions are completely messed up by this >> approach. Userspace authors get the choice when they write their code. >> Even if the caller has turned on strict, if you haven't added strict >> types to your functions/methods you are fine. Internal API and extension >> authors don't get this luxury. If the caller turns on strict, then >> suddenly an API that was written explicitly to make use of the coercive >> characteristics PHP has had for 20+ years breaks and there is nothing I >> can do about it as an extension author. This is beyond just int->float >> coercion, which is, of course, also missing. >> > It's not your problem how a script author choses to use your function.
I would very much like it to be my problem how my API is exposed to a
user. At the very least I should have as much control over an API
written in C as one written in PHP. Currently with this RFC it is not
the case and worse, it is retroactively changing an existing set of
functions to be all-strict when this mode is turned on. Even with strict
mode enabled, userspace is not retroactively turned strict and you can
slowly transition your API to be strict by adding appropriate strict
types in a controlled fashion.
And this fact is quickly glossed over to the point where I believe a lot
of people didn't even realize that they were voting for a retroactive
all-strict internal API. But hopefully I am wrong on that point.
> We can sigh and tut about this not being "the PHP way", but the script
> author was the one who chose to enter into a tight contract, and the
> script author, not you, is the one who should have that authority over
> their own application.
I find this view way too extreme. Not everything is this black and white
in the real world. We have to be really careful that we don't give the
illusion of better while we make things worse for people. In the real
world, you know for a fact that people are going to force-cast stuff and
they aren't necessarily going to be very careful about it.
The illusion being strict is better than weak-coercive, so let's turn on
strict everywhere. Oh, damn, some stuff broke. Throw in some casts,
things work and hey we are now safer because we are strict. Where in
reality "strict+force cast" tends to be worse than "weak coercive" as
per the number_format((float)"dog") example.
>> And how do you think users will deal with internal functions that are now
>> suddenly strongly typed even though they were not designed to be?
>>
> I think they'll deal with it by dint of having /chosen/ to turn on
> strict typing. It's not as though an upgrade to PHP 7.12 suddenly
> made all their code strict without warning. In fact, nothing will
> have changed for them at all UNLESS THEY EXPLICITLY ASK FOR IT.
Right, but they will want to start using strict, or else what are we
even talking about? And as soon as they do that string that comes back
from their ORM and passed to number_format() now needs to be dealt with
somehow. I'll bet you a Tim Horton's doughnut that a depressingly high
percentage of people will simply toss a (float) cast on it and move on
and by doing so they have made their application worse.
> Again, you're assuming a single method call in a vacuum. Is it
> possible that the kind of script author who is turning on strict
> typing might, in fact, be strict in the rest of their application?
> Might, in fact, not try to pass a resource into a function expecting
> float because they have the tools of strict typing available to them?
That's a lot of assumptions. Library functions get data from all sorts
of edges that are outside of the scope of simple type checking on
function arguments. I'd rather not encourage incorrect behaviour here by
retroactively changing the API like that.
> So let's talk compromise.
> Would leaving internal functions out of the picture at this stage
> change you mind? This is effectively what Hack does, internal
> functions are explicitly marked as "coercible".
> Would a tri-state option make sense? ('weak-all',
> 'strict-user/weak-internal', 'strict-all')
> How do we get from here to something you would like?
So in Hack you didn't think it was a good idea to change the internal
and extension api either? Was the reasoning similar to mine? Did you
agree with the reason then but not now?
-Rasmus
signature.asc
Description: OpenPGP digital signature
