Hi Zeev,
> On 15 Jan 2015, at 15:10, Zeev Suraski <z...@zend.com> wrote:
>
>> Let’s have a look. From a quick skim over the thread for v0.1:
>>
>> * In favour of weak types (or the RFC anyway): Adam, Stas, yourself,
>> Jordi,
>> Pierre,
>
> You're definitely missing Dmitry (which helped with the RFC) as well as
> Xinchen and Arvids from today. From past experience I believe Rasmus too.
Yeah, I’m probably missing one or two from skimming over the previous RFC
thread.
>> * Against, in favour of strict types: Maxime, Nikita, Markus, Marco,
>> Leigh,
>> Levi, Sven(?)
>
> As far as I recall (maybe I'm wrong) the only one here that outright opposed
> was Nikita. Others suggested ways to improve it but didn't really oppose
> it.
Maybe. I don’t think Nikita was the only one opposed, but I may be wrong.
>> It is very clear to me that a lot of people would like strict types, and
>> some
>> people would like weak types. As to their relative numbers, I cannot say.
>
> Well, that's clear bias right here too - 'a lot' vs. 'some'. Again, I don't
> think you have a way of knowing it and based on my experience the opposite
> is true - but none of us truly knows. Either way, the former goes against
> what we created PHP around, while the latter does not.
Tradition isn’t everything.
>
>> I don’t think it’s really fair to cover only the use case of one half of
>> the PHP
>> community. The other half counts too. This is a rather divisive issue.
>
> I disagree. PHP has never been about everything and the kitchen sink. Not
> only do we not strive to support everyone's taste, we actually try not to,
> and be somewhat opinionated on how things should be done.
> This issue is primarily divisive among the inner core of the PHP userbase,
> hardly around the millions of users out there.
Supporting strict types isn’t “everything and the kitchen sink”. Sure, we do
not need to cater to everyone’s taste. But we shouldn’t do things which are
unpopular, and weak types, depending on who you talk to, would be that. Strict
types have a lot of support from parts of the community.
>> I don’t think this is true: if we are making a feature less useful (and
>> therefore
>> making many people avoid it), it’s worth considering if that is a problem.
>> If
>> we can easily cover the vast majority of people’s use cases, rather than
>> catering to only one group of people (who may or may not be the majority),
>> why don’t we?
>
> For the same reason we didn't introduce strict types in the countless times
> it came up in the past - it goes against the language's principles.
It is not necessarily in conflict. We have, after all, had strict typing for
non-scalars for, what, a decade now?
>> Except that is not the case for this proposal, which explicitly and
>> deliberately
>> prevents the directive affecting inclusion. The behaviour is impossible to
>> toggle at runtime, unless you’re using some weird extension which lets you
>> edit the flag on the ZEND_DO_FCALL opcode.
>
> Fact is that people who run websites where they don't care about strict
> typing, can end up viewing strict type failures coming from code they don't
> own, which would make the app fail 'catastophically' and unpredictably.
That can happen in any case. Failures in libraries will always cause problems
for users. If the library is broken, the user is screwed anyhow, there’s very
little they can do about it.
> You'd have no way to turn it off (without diving to and changing the file in
> question) - because it's the code itself that turns it on - and from the
> user's point of view, for all practical purposes, at runtime.
In what way is it “at runtime”? It’s a per-file setting. What it does is no
different from manual assertions on each line of code.
“Runtime” implies something that can actually be changed at, well, runtime.
This can’t.
Are you opposed to people using type assertions in their own code (not entirely
uncommon) along the same lines? The following two code snippets are essentially
equivalent:
declare(strict_typehints=TRUE) {
foo($bar, $baz); // foo() takes an integer and a string
}
vs.
if (!is_int($bar)) {
throw new Exception(“Not an integer”);
}
if (!is_string($baz)) {
throw new Exception(“Not a string”);
}
foo($bar, $baz);
It is a property of the code, it’s not “at runtime”.
Heck, if code in a library that you’re using breaks because of strict hints,
you probably can’t fix it anyway because something was probably seriously wrong.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
