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.
Is it a bug in PHP that currently I can call number_format() with an
object? No. number_format() was written to take a float, and accepts
ints and numeric strings as a byproduct.
Adding the option on a per-file basis to make that call strict doesn't
change the intent or the usage of number_format(). number_format()
still gets a float and still acts on that float in the same way. All
that changes is whether passing an int or a numeric string is
considered "wrong" or not.
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.
> 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.
> Do you think they will go look at the source code for the function and mimic
> the data sanity checks and put those in their userspace code?
>
No, they'll look at their own code and make a more informed decision
than any extension author can make for them.
> Out of the 3 scenarios, this is inarguably the worst outcome with the
> last line there being the most blatant. Actually outputting an internal
> resource id as if it was a valid number to be formatted without the
> slightest notice or warning anywhere that something is wrong in the code.
>
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?
> This is my fear with this approach. People will start littering their
> code with casts and it will hide real bugs which is the complete
> opposite of what motivated this in the first place.
>
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?
> Without more thought into how we properly deal with internal/extension
> code I don't really understand how so many people foresee this to work
> perfectly in the real world.
>
<kidding>This would be an opportune time for me to quote you as saying
you're really not that into languages. :)</kidding>
As I said above, I foresee this working well in the real world because
nobody is acting in a vacuum, there's an entire application's worth of
type-checked code going into it.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
