Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75518
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.91 as permitted sender)
Message-ID: <53C464D3.9090501@sugarcrm.com>
Date: Mon, 14 Jul 2014 16:16:35 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Zeev Suraski <zeev@zend.com>, Andrea Faulds <ajf@ajf.me>
CC: Rowan Collins <rowan.collins@gmail.com>, 
 "internals@lists.php.net" <internals@lists.php.net>
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <alpine.DEB.2.10.1407141536380.4247@whisky.home.derickrethans.nl> <AF61F548-FADC-428F-B76F-1BB82C645D2C@ajf.me> <alpine.DEB.2.10.1407141552290.4247@whisky.home.derickrethans.nl> <53C3F70A.7010706@gmail.com> <3aa29e080d70c843713e19a952dfbad6@mail.gmail.com> <A1902C97-2854-44C8-AA76-2551DF3F05E5@ajf.me> <3b06c592b0b88bb95d3ae7ea7a93d86f@mail.gmail.com> <6AF150D1-1398-43CA-977A-3CF3D51719F4@ajf.me> <5b53012f7b5437d85cdf9972194aa34f@mail.gmail.com> <53C408EC.7080104@gmail.com> <5f491f470e902489f036102ae0f437f8@mail.gmail.com> <53C41244.5010505@gmail.com> <8177fae7c5a1a21ab2bc2b98d7e29d17@mail.gmail.com> <3F4D195C-256C-443D-A92A-E130776C4E88@ajf.me> <ac3d4219cb866920b379c061b37fdfbd@mail.gmail.com>
In-Reply-To: <ac3d4219cb866920b379c061b37fdfbd@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

>> cast to them, sure, because PHP as a rule allows you to cast anything to
>> anything explicitly (bar resources), but I can't, for example, do a
> loose
>> comparison between an array and a string.
> 
> Exactly, that's my point.  While you can explicitly cast scalars to arrays
> and even objects, it's an edge case and arguably a misfeature, and (IIRC)
> never happens implicitly.  And of course there's no way to turn a scalar
> into a specific type of object or a resource.

We can take another option, which would be a compromise but still allows
us to preserve the consistency:

We can define casts as being two types - implicit cast and explicit
cast. Implicit cast would be anything where value of one type is used in
a context requiring value of another type, and would be roughly
following what we do now, with the exception of some most weird cases -
like array->string, non-array->array, resource->int/string, etc.
excluded (excluded meaning throwing an error, I am not specifying which
one as it is not important but probably the same kind as if you try to
pass "42" to function expecting SplArray).

Explicit cast would be the one used when you do (type), and this one
would include maximum possible conversion - i.e. in this case we would
permit casting anything to array, casting anything to string, and other
casts that we could give any meaning whatsoever without going completely
bananas. Of course the cases covered by the implicit cast should work
the same with the explicit cast.

We kind of already have it with (object) cast - you can not cast
anything to object implicitly, but can do an explicit cast - I just
propose making this a robust framework instead of one-off case.

With this, parameter types would naturally be a candidate to use
implicit casts when needed, while being consistent with the rest and
while still allowing forced casts in case we just don't care if any loss
occurs.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/