On Mon, Feb 16, 2015 at 6:55 PM, Rasmus Lerdorf <ras...@lerdorf.com> wrote:
> 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.
>
And you have that control. You expose number_format() as taking a
float, and it does, in weak and strict modes alike.
> 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.
>
That's a dubious distinction. The "special" treatment of internal
functions is due to them having types defined. Of course userspace
functions don't become immediately strict since they don't
automatically have types.
> 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.
>
It's presumptive to assume you know what people are basing their votes
on. You're better than that.
>> 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.
>
You find giving authority over an application to the application
author 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.
>
THIS point I agree with in principle. Some developers are going to
misuse this feature. That's true of every feature. It was true of
goto, it's true of the input filter extension, it's true of PDO
prepared statements. People use stuff the wrong way. That doesn't
mean we should sacrifice functionality for everyone.
> 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.
>
And a hearteningly high percentage will use it the right way. I'll
buy you that doughnut and have one myself.
>> 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.
>
It's one assumption. That there exists a population of PHP developers
who actually know how to program. I'm sorry you don't think that's
the case.
>> 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?
>
First, I'd like to note that you seem to be ignoring my question.
** How do we get from here to something you would like?
Second, I should clarify that while the HHVM runtime performs
coersion, the hack type checker is strict. So my original statement
was inaccurate. As far as hack is concerned, it's simply strict.
Period.
Third, Not everything done in hack is in line with what *I* would
like. Don't mistake me for hack.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
