Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83500
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.181 as permitted sender)
Message-ID: <54EA5AE2.5090605@gmail.com>
Date: Sun, 22 Feb 2015 14:40:34 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: =?UTF-8?B?SmVmZmVyc29uIEdvbnrDoWxleg==?= <jgmdev@gmail.com>
CC: Etienne Kneuss <colder@php.net>, 
 Anthony Ferrara <ircmaxell@gmail.com>,
 Zeev Suraski <zeev@zend.com>, PHP internals <internals@lists.php.net>
References: <7ef509ef10bb345c792f9d259c7a3fbb@mail.gmail.com>	<CAAyV7nHq_-9jyRcwJmiAxthmEo3u3MDXcyOC09LV2DETABzCoA@mail.gmail.com>	<8250289916f5128b5bc1a114428d374e@mail.gmail.com>	<CAAyV7nHAicJCQU87YkhZ700a=k4MRqVJtMV-mG4F0MQsn82OfQ@mail.gmail.com>	<CACQesk5cqzWD4jGSsv7b1ZoiinL7vyC5ZSZ2nemTMuKfUwqk2Q@mail.gmail.com>	<54E9E6B5.3030905@gmail.com>	<54EA3E59.3000706@gmail.com> <CAP-p_+2+mAhr-O6eD5KbFG0p6=320WirSq4Vzct=nMmHGBNjZw@mail.gmail.com>
In-Reply-To: <CAP-p_+2+mAhr-O6eD5KbFG0p6=320WirSq4Vzct=nMmHGBNjZw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> Well, strict on a JIT environment may haven't been proved, but it surely
> has been proved on statically compiled languages like C. Currently, a

I understand that using the same concept of typing in both cases can be
confusing, but that's pretty much where the similarity ends. Strict
typing in C has very little to do with what is proposed as strict typing
in PHP, and so far nobody is considering making PHP strictly typed in
the way C is (let alone more strict languages than C are). So bringing C
into the discussion is misleading.

> JIT in the most cases can't compete to the bare performance of a static
> compiled language, both in resources and CPU, so how is non strict
> better in that sense? 

Dynamic typing is not better in that sense. That's my whole point - from
the JIT perspective, they are the same, so the claim that strict typing,
as proposed, provides performance benefits, is incorrect.

> previous message, at runtime it consumes more memory and cpu and this is
> mostly due to all the type checking it requires. In that sense if the

As I already mentioned, current strict proposal requires type checking
too. The only one that doesn't is complete strict typing at compile-time
- which nobody is proposing.

> strict proposal could improve that situation it would be a benefit.

You keep repeating that, but that claim does not become more true
because it is repeated more times. It still is as unsubstantiated and
lacking base as it was the first time it was introduced. Please provide
some proof (logical or experimental) as to why it must happen (yes, this
includes the "if" too since it is pointless to bring it as a possibility
if we do not have any way for this possibility to be realized).

> I thought those checks could be optional if generated at call time,
> thats why I gave these 2 examples:

I don't see how they can be "optional" with strict typing.

> 
> calc(1, 5) -> no need for type checking or conversion, do a direct call
> calc("12", "15") -> calc(strToInt(value1), strToInt(value2))
> calc($var1, $var2) -> needs type checking and conversion if required

The same can be said about dynamic typing, with exactly the same words.
The only difference is what happens *after* checking - but this is only
relevant if the code relies on conversions, in which case in strict case
it just won't work - hardly a performance improvement worth considering.

> I was thinking on the sense that before calling a function, type
> checking could take place and conversion if required, but may be thats
> even more complicated...

This can be done in dynamic case too, provided the type information is
present (i.e. constants). No current proposal does this, though, AFAIK.

> Static typed languages -> Direct conversion to machine code
> Dynamic typed languages with JIT -> Intermediate representation ->
> Checks -> Conversion to machine code with checks.

We're not talking about making PHP statically typed language, do we? So
this advantage - while without any doubt real - does not apply to PHP.
-- 
Stas Malyshev
smalyshev@gmail.com