Hello Andrea,
On Thu, Jan 15, 2015 at 8:09 AM, Andrea Faulds <a...@ajf.me> wrote:
> Hi Zeev,
>
> > On 15 Jan 2015, at 11:56, Zeev Suraski <z...@zend.com> wrote:
> >
> > Andrea,
> >
> > I'm not sure what you're basing that assumption on. The incidental
> > interactions you (or anybody) may have with 'the community', by no way
> > represent the opinion of the community at large. The vast majority of
> the
> > PHP community never ever interacts with internals@, never attend
> > conferences, don't write blog posts about PHP and are generally
> completely
> > 'under the radar'. I would actually go to argue that the people who do
> > attend conferences, participate on internals@ or write blog posts - are
> not
> > representative of the PHP userbase at large. The vast majority of
> > developers I bump into - you will never ever hear from. They constitute
> the
> > vast majority of the ~5M strong PHP developer base.
> >
> > So even though my belief / educated guess is that the vast majority of
> the
> > PHP userbase would prefer to see strict typing kept off this language,
> I'm
> > not going to argue that - but we must not argue the opposite either,
> based
> > on the non-representative anecdotal data from a few dozen people.
>
> Whether or not they are in the majority, a very large portion of PHP
> developers would prefer strict typing. In particular, the most vocal ones
> would seem to. There are also a lot of PHP developers who would prefer weak
> typing. Thus we have a problem: either approach to scalar hints will upset
> a large portion of the community.
>
I actually quite disagree with that statement. Both as a library/framework
developer and a user land developer I find strict typing to be more of an
issue. For instance:
function foo(int $foo)
foo('23');
This would be a pain and cause constant glue from userland:
Option A: Force Cast aka (int) '23'
Option B: Check for digits via ctype_digits then force cast
etc.
To provide more of a point here, variables coming from HTTP are always a
string, this makes strict casting a troubling item, considering that the
main way of fetching input is coming from the web specifically. I'm
certain this would also affect other areas as well such as reading csv
files and more. To me this point alone makes a vastly strong statement
against strict typing and as such, it would make life far more difficult
for library developers and user land developers alike.
>
> >
> >> Myself, I might have been somewhat happy with just weak hints, but
> >> it would upset an awful lot of developers who would like some measure of
> >> strict typing. Developers who would most likely not use the new scalar
> >> type
> >> hints, because they weren’t strict. And if nobody uses them, why add
> them?
> >
> > How do you deduce that 'nobody uses them' from the fact that some group
> of
> > people said they won't? I'm sorry, but it makes no sense, especially
> given
> > the positive feedback you saw on internals, making it clear that there
> would
> > be in fact people using it.
>
> Not all of it was positive. Sure, a lot of people would use them though,
> but I’ve heard quite a few developers say they wouldn’t use them and
> continue to use manual (!is_int($foo))-style assertions.
>
> > If there's one thing that's worse than introducing an alien concept like
> > strict typing into PHP, it's introducing it as a feature that will
> include
> > all the negatives of this alien concept, PLUS have the ability to
> radically
> > change how it behaves based on a runtime option.
>
> This isn’t a runtime option, it is entirely compile-time. Much like
> namespaces are not a runtime option. There isn’t even the ability to toggle
> it at runtime, unless we somehow add some ability to edit the flags on
> individual opcodes.
>
I agree with the others in that declarative syntax to change it is a bad
idea. It actually reminds me of ECMAScript 5's "use strict" (
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode)
condition. Changing the definition based on user land scripts can lead to
bugs and inconsistencies in a library developers purpose of a package and
cause bad conditions. It also means that then a library developer would
need to handle conditions on both sides (when in weak vs. strict). So I
don't really understand where the gains of this would come from and it
actually causes me concern in that what if a developer forgets to define
strict and you're entire system is built on strict.
Regards,
Mike
