Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80094
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain seld.be designates 74.125.82.179 as permitted sender)
Message-ID: <54A6A4D3.9070808@seld.be>
Date: Fri, 02 Jan 2015 14:01:55 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <41D5BB0B-73AF-488E-968D-90B2878E3178@ajf.me>	<CAF+90c-uiLj1QoT+dXfd1obRXNcYcpBAJ-aU59yEXk+HYNZRFw@mail.gmail.com>	<54A5DF14.7000105@gmail.com>	<CAF+90c8g+vVC9YDSPrGTb-K+-KDwV1a1=8rf3BH-sHJYOh3TmA@mail.gmail.com> <CAFMT4NpGfew5qyrYFQ0qf8ATQf1ZH613VT9O7EosWJ=GA=q3ww@mail.gmail.com> <54A678EA.4070706@fischer.name>
In-Reply-To: <54A678EA.4070706@fischer.name>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints
From: j.boggiano@seld.be (Jordi Boggiano)

On 02/01/2015 10:54, Markus Fischer wrote:
> On 02.01.15 05:36, Levi Morrison wrote:
>> I don't necessarily have any more insight to provide than has already
>> been done, but I do want to chime in and say that I personally favor
>> strict types as Nikita Popov has been advocating.
>
> Same from me. I support all arguments so far made by Nikita; they're
> well laid out, better than I could have done it.

And I, on the other hand, disagree.

Looking at it from an OSS maintainer perspective, introducing strict 
hints in code would be a huge BC break as I don't know how people use my 
code, nor if they validate/coerce their user input early or not. If I 
suddenly declare something as int and someone used to pass '5', they get 
an error. That would make adoption quite hard in OSS IMO if you don't 
want to bother people.

With weak typing on the other hand, I get to remove tons of @param 
annotations which would be amazing, and I get additional safeties that 
*new* mis-uses (like passing an object in an arg expecting a string, 
which at the moment could not be type hinted) will be caught early in 
the future.
Existing mis-uses probably don't exist much since they'd likely fail 
further down in the code execution already, but in case they don't 
they'd be caught too and that's a good thing since it makes people look 
at their buggy code.
As for valid uses of the code, like the '5' above, it keeps working just 
fine because it is fine. It's not my call as a library author to decide 
whether the users of the lib should cast user inputs to ints or validate 
them or do nothing at all.

Besides, IMO if strict typing was so desirable we would see more of the 
String/Int classes out there, or we would see people do things like:

    function foo($number, $string) {
         expectNumber($number); expectString($string);
    }

That'd be a simple lib to write, it barely adds more code to your 
functions, and you get strict typing. But I hardly see anyone do this, 
and I would argue it's because it sounds appealing in theory but it's 
not worth it in practice.

Cheers

-- 
Jordi Boggiano
@seldaek - http://nelm.io/jordi