Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75590
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.182 as permitted sender)
Message-ID: <53C67265.5010201@gmail.com>
Date: Wed, 16 Jul 2014 13:39:01 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <16D48604-0C0A-4613-91A4-21392E3A2636@ajf.me> <CAGAGxbZG+c46P4E2pmEHNnEv=4DyTrHOuXbZu3zAOSU3M6-A-A@mail.gmail.com> <05CE2216-C5D9-4937-9F2E-AA1407284D9F@ajf.me> <53C460DF.5040304@sugarcrm.com> <53C53A96.2040303@gmail.com> <53C55342.1010207@sugarcrm.com> <53C563B3.6060905@gmail.com> <CAPhkiZwvqW=d3Ayn-=Hx5HfkcOFB+gQ6rRoFThxA8hESK4WLrA@mail.gmail.com> <54536191-1B92-4933-973F-0C8289D13A4C@ajf.me> <00d12255efc53466245b21a83ff7d474@mail.gmail.com> <53C652FA.6010704@gmail.com> <d15e014a0b7a7a244c30b02c849ed7b3@mail.gmail.com> <53C66D6E.9060200@gmail.com> <60f496756412de6ad97751d91ead5058@mail.gmail.com>
In-Reply-To: <60f496756412de6ad97751d91ead5058@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: rowan.collins@gmail.com (Rowan Collins)

Zeev Suraski wrote (on 16/07/2014):

> But there too, they'd have consistency, just one set of rules for
> implicit cast of scalar values across all of PHP.

The way I see it is that there's an existing set of rules for the result 
of any cast, implicit or explicit; these are in some cases "lossy".

Various proposals here rely on a separate set of rules, which doesn't 
modify the *result* of any casts, but *checks* that the cast will be 
"lossless".

The RFC as drafted proposes using these new checks in one specific place 
(function calls when declared with type hints) and with a particular 
outcome (catchable error).

As far as I understand it, you propose defining *the same set of rules*, 
but applying them in a different place (whenever an implicit cast 
occurs) with a different outcome (emit a new E_CAST message).

> The proposal currently on the table implements two, simultaneously active
> sets of rules that in the long run everyone will have to be aware of.  It
> has both the lossy and lossless concepts active in the same time, which
> means everyone will have to become familiar with the lossless rules, whether
> he's interested in that or not.

Right, so it's not actually about the existence of the rules, just the 
likelihood that someone will be able to ignore them? Someone writing 
code from scratch can, of course, not use any type hints, and so ignore 
the checks either way, but I guess if some project or library adopts 
them, developers will need to learn how they work to interact with that 
project/library.