Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84618
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
Message-ID: <5501582A.7020905@lsces.co.uk>
Date: Thu, 12 Mar 2015 09:11:06 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <ff8e8d5564b00b7baead3d9dd46282c8@mail.gmail.com> <CAEZPtU6wQtLeotvsCShHkU2g+Fo115b7NUGfAGvu88FyH-odrw@mail.gmail.com> <550149E1.9030904@olemarkus.org> <b294ef96e9d5a5fb9747530d1c7523e5@mail.gmail.com>
In-Reply-To: <b294ef96e9d5a5fb9747530d1c7523e5@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
From: lester@lsces.co.uk (Lester Caine)

On 12/03/15 08:29, Zeev Suraski wrote:
> There have been NO big changes to the proposal - only two tweaks which I
> clearly detailed in the Vote email, that have been publicly discussed in
> detail on internals@ more than a week ago.

Zeev ... being realistic I think that the chances of getting another 48
votes in favour are unlikely as are the chances of blocking the other
proposal?

The problem here is that a large number of people want type hinting one
way or another and there is not a strong enough case being made NOT to
bow to that will? So the next problem is perhaps how do we live with a
section of the developer world adding hints to well established
libraries? During the move to PHP5 one could quite happily write code
that continued to work on the majority of PHP4 systems, The move to PHP7
needs the same set of guidelines, so what is currently being championed
which will mean that we have to maintain a PHP5 version of a library
from day one of PHP7 and what do we avoid in order for PHP code still to
run on PHP5?

I still have to be convinced that adding a half baked variable check
does have a major advantage. YOU have demonstrated the various transfer
paths although they lacked the finer detail type checking that already
happens in many code bases such as the range of the number passed.

The bit I am more concerned about is the further dilution of the
docblock annotation as people will adopt type hints in place of the
already existing annotation and again we loose a lot more than we gain
:( Personally I would much prefer that this was picked up properly again
as other RFC's are trying to do, and I feel that answers all of the type
hinting ad other static analysis problems that some people seem to think
are so important. Expansion of the docblock 'standard' will also allow
range of variables to be managed, yet the whole lot can be striped and
ignored once one is out of 'design' phase.

Is the final endpoint target here that like python, PHP will become a
two stage process with compiled versions of user land code?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk