Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80109
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fischer.name from 62.179.121.34 cause and error)
Message-ID: <54A7112E.6020205@fischer.name>
Date: Fri, 02 Jan 2015 22:44:14 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; 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> <54A6A4D3.9070808@seld.be>
In-Reply-To: <54A6A4D3.9070808@seld.be>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Spam_score: -2.9
X-Spam_score_int: -28
X-Spam_bar: --
X-Spam_report: Spam detection software, running on the system "scanner01.home", has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Hello Jordi, On 02.01.2015 15:01, Jordi Boggiano wrote: >
   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. [...] 
 
 Content analysis details:   (-2.9 points, 5.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
                             [score: 0.0000]
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints
From: markus@fischer.name (Markus Fischer)

Hello Jordi,


On 02.01.2015 15:01, Jordi Boggiano wrote:
> 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.

I'd argue if your concern is so big, you just wouldn't do it ... it's up
to the author how he sees it fit and wants to use it. You could make all
your public facing methods don't use them but only use it internally
(aha, just saw someone mentioned this in another email too; weird).

> With weak typing on the other hand, I get to remove tons of @param 
> annotations which would be amazing
[...]

I hope you don't because @param should also be describing the
purpose/usage of the parameter ;-)

> 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.

That's really interesting, because I as library author actually do
provide "how to use my library". I mean:
- I create it with my vision
- I document it
- I create the examples how to use it
- I decide what's private/protected/public, i.e. how extensible things are

Well, there's lot of "I" but that would also apply to teams and their
decision how to use it.


My want-to-be-on-the-safe-side-code currently is either riddled with
explicit casts or simple nothing; I try to keep my methods small and
that overhead could outweigh code logic sometimes which I'd consider
counterproductive.
> 
> 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:

Well, performance; manual boxing/unboxing is IMHO not really feasible to
do with the interpreter currently (ok; gut feeling here, no benchmark).
So, yes, I would use it if the overall overhead incurred would IMHO just
not make it feasible. (sorry for repeating)

> 
>     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.

I'd love to to that but simply also don't want to clutter my code with
such an approach.

The current situation to me is a bit like: it bothers me, but not to the
point I'd clutter my code with an approach like you've shown (and was
tempted multiple times in the past to do ...)


Although it seems like I wrote so many "counter" argument, please don't
misinterpret. For the love of history I merely told my view and I'm
actually glad you shared yours; with this important topic for PHP,
however it ends, there can't be too many views on that matter.

thank you,
- Markus