Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82638
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <e5c2a94f09de8ea45f06c63b5cda36ef@mail.gmail.com>
References: <CACwt+JdHCYYVMbuuAZ73N_sfOkQHJ7_EkOtPWtqJcNW7Xgjn3w@mail.gmail.com>
	<EE83CD8A-BAFA-43AC-8CD0-5F123BF96299@ajf.me>
	<93453174-E6A8-47C6-8AB6-A08858A7FC05@zend.com>
	<CAAyV7nH0BVvoq0XpGAX=ve2j9RwgUvti+DvR0c7v2BiALg4XWg@mail.gmail.com>
	<e5c2a94f09de8ea45f06c63b5cda36ef@mail.gmail.com>
Date: Sat, 14 Feb 2015 01:40:09 +0700
Message-ID: <CAEZPtU6xR1eF2L+LYvCC7FZfReXsOq=2QF=bbp1si+cOP94KVQ@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
From: pierre.php@gmail.com (Pierre Joye)

On Sat, Feb 14, 2015 at 1:20 AM, Zeev Suraski <zeev@zend.com> wrote:
>> With that said, there's nothing stopping you from putting up your time to
>> create a competing proposal and patch. If you really believe that weak
>> types
>> are the better way forward, why not codify that? If only one of the RFCs
>> passes, then you have your answer. If both pass, we can simply have
>> another
>> vote to choose which to move forward with.
>> Competition is healthy for the community.
>
> That may be a good idea.
>
>> You also said earlier in the thread that you don't agree with the points
>> that I
>> made on my blog post (http://blog.ircmaxell.com/2015/02/scalar-types-and-
>> php.html). Can you share what you don't agree with (in the comments or
>> this
>> thread)?
>> Rasmus posted some issues, most of which I consider details in this
>> proposal
>> (declare() and lack of handling the int->float conversion
>> case) and I replied to them (I think they are handleable). If you have
>> other
>> disagreement, why not share?
>
> I've shared them countless times over the past decade.
> Strict typing exposes data that should not be interesting in the vast
> majority of cases and makes it prominently available for handling using
> native syntax.  That's bound to make a lot more developers care about the
> internal type of scalars, and rely a lot less on PHP's dynamic typing - or,
> in other words, make PHP a more complex language.  While Andrea's RFC does a
> significantly better job at hiding strict typing from uninterested parties,
> ultimately, mostly everyone will bump into it and have to accustom
> themselves to a typing behavior that's never ever existed in PHP.  Two
> examples that come to mind are people working on shared code (not exactly an
> uncommon occurrence) and variables that find their way into internal
> strictly-typed calls, which would result in obscure messages for someone
> that's used to "32" and 32 to be virtually identical in PHP.
>
>> I would especially would like a response to the point that I made where I
>> showed 3 examples where weak hints of any type would cause subtle and
>> hard-to-find bugs; one of which was a high-level security risk.
>
> Languages have advantages and disadvantages.  PHP's biggest advantages is
> developer productivity, and dynamic typing is a big component of that.  Does
> it have disadvantages?  Sure.  But PHP was designed with the belief that the
> advantages of dynamic typing outweighs that of strict typing.  In the few
> cases where strict type checking is needed, you have the facilities to do
> that in a bit of custom code.  That balance of making strict type checks
> possible - but not at the level of native constructs - is the right balance
> for a dynamically typed language like PHP.  You'd only add strict type
> checking if it's really needed, and not as an afterthought.
>
> To your examples, I'm not at all advocating the use of an arm's race to put
> typing information - weak or strict - everywhere.  Of course, if you place a
> weak type hint in a situation where type conversion would pose a high
> security weak, it's a mistake.  Keep the handling in  custom code in such
> cases.  In most scenarios, however, that's not the case.  And in even more
> scenarios - there's no need for any kind of scalar type hinting at all.
>
>> One final side-point: In my work on Recki-CT, I learned very early on that
>> casts are quite expensive. When compiling mandel() from Zend/bench.php,
>> the implicit casts that were happening on $w2, $x and a few other vars
>> (which were ints) to floats for the computation added approximately 10% to
>> the runtime of the function. The casts in mandel2 accounted for 20% of the
>> runtime. Let me say that again: the
>> int->float conversion in the loops accounted for between 10% and 20%
>> of the function call. And that's not a dynamic cast (a branch based on
>> type),
>> it's a single `fild` instruction. Having the ability to statically know
>> that a cast
>> will never be needed can result in significantly faster (and easier)
>> native code
>> generation...
>
> Two points on this one:
> 1. PHP's motto has always been developer productivity over performance,

That makes my day. And I will leep this quote in mind for any future
discussions about new additions.

> if
> squeezing performance meant bothering the developer with implementation
> details he shouldn't care about.   We prefer to work hard on getting the
> engine optimized, and let the developer focus on creating the business logic
> in the simplest possible way.  By the way, in this particular case, it's
> possible to automatically detect that the variables in question are all
> floats, and have the engine automatically do it for you.  It's not easy, but
> can be done.  If we ever have JIT in PHP, it will do that automatically for
> developers - which is exactly PHP's spirit.

And it will still be possible with this RFC. And this RFC allows
better and more efficient way for strict areas, especially for
functions/methods calls.

> 2. More importantly to our discussion, there's zero practical difference in
> terms of performance implications between weak and strict typing.

> Everyone forming their opinion regarding weak vs. strict vs. both should
> know there's no performance impact to be expected from any choice we make.

And it is not about performance, never was and should never be.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org