On 02/17/2015 01:30 PM, Zeev Suraski wrote:
Yes, I already know that.
The difference, and why I keep pointing that out, is that me and many
others
want strict typing for our own reasons (but still in its entirety instead
of as a
limited mode) and most of us don't even care if you getting weak typing
for
your own usage. You can't work towards consensus if your target is to
prevent the opposing group of getting what they want. I see both as
valuable
tools for different jobs and I want to have more tools at my disposal,
while
you're trying to tell me that I should use only one tool for everything.
First, it's very important to understand that my target is to prevent the
opposing group from getting what they want. I'm really not sadistic :) My
reasons were obviously different and worked towards a different goal. Much
in the same way that people who vote against an RFC - one of the countless
that were voted against - don't do that to hurt the ones who support it.
They do it because they think adding it would bring negative consequences.
I never believed the 'You don't have to use it' as a silver bullet
explanation for why it's OK to add features with potentially negative
implications.
The good news is that I think that in many ways the ideas we're toying with
right now are better for the strict-type camp, especially if we end up going
for just one mode, and meet roughly mid-way in terms of strict and weak -
which I think is doable. The biggest gripes strict campers had with weak
mode are gone in this proposal, and unlike v0.3 - that would actually be the
default (and only) behavior, which is a big gain for the strict campers.
And the most prominent features of weak typing are kept (dynamic type
conversion where it makes sense), hopefully making the weak campers happy
too.
But you implied that most objections were from people who don't want
strict
typing in PHP at all. And I disagree with that because it's a speculation,
which
in turn you are using to favor your weak-hints-only case (hence, twisting
it in
another direction).
I didn't imply it now (at least I certainly didn't intend to). I did
outright say it a week or two ago, and still believe that's the case but
reached the conclusion that none of us would gain anything from further
discussing it. We won't know unless we start actually polling the people
who voted and ask, which we're not going to do, and we're obviously not
going to convince each other. Much more importantly, it at least *seems* as
if we have a direction for something that a very wide audience may rally
behind. Let's focus on that!
Zeev
At this point, if I could rephrase the "camps" a bit I see two different
sets of priorities:
1) PHP should do what seems "obviously safe" to do, to make life easiest
for developers. That is, it's patently obvious that "32" and 32 are
equivalent, so don't make developers worry about the distinction because
to them there isn't one. This is an entirely reasonable position.
2) PHP would benefit hugely from static analysis tools and compile-time
type-based optimizations, but those are only possible with code that is
strongly typed. Currently such tools do not really exist, but with
compile-time-knowlable information could be written and even
incorporated into future versions of PHP without API breaks. (I think
Anthony demonstrated earlier examples of function calls no longer being
slow, for instance, if the type juggling could be removed at compile
time.) This is an entirely reasonable position.
Naturally those two positions are mutually exclusive; if the compiler
has to allow for "32" to be converted to 32 at runtime, it can't
optimize the opcodes by removing the code that would do that conversion!
I was against the mixed-mode approach before, but I given the above I am
warming to it. The trade off here is between DX (in the sense of the
code "doing what I mean" and not babysitting type information) and
potential performance and bug-finding benefits. Different places in an
application may need different trade-offs. In practice, the closer you
are to an IO action (browser input, database, file, etc.) the more you
want the "obviously safe" behavior; once you pass one layer of specified
typing you can be pretty confident that strict checks will "just work"
from there on out.
In essence, opt-in-strict becomes an opt-in "compiler, be pedantic so
you can make my code faster" flag. More carrot than stick, since people
can control when they opt-in to fancier compiler optimizations at the
cost of some DX, but only in some cases.
I started this email planning to ask Anthony how flexible strict
checking could get without losing the benefits of it, but I think I've
just convinced myself the answer is "not very". Which then leaves only
the question of internal functions that Rasmus raised, which... it looks
like is discussed in later emails so I will try to catch up on those. :-)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
