Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75437
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.182 as permitted sender)
Message-ID: <53C2DC03.2050609@gmail.com>
Date: Sun, 13 Jul 2014 20:20:35 +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> <CAF+90c-ojALBgeyXu+f2tW6LoW8+4XGVpu_+i9SyX=u4RSoxug@mail.gmail.com> <027E65EF-C4FC-474C-92BB-D99EFADDEEED@ajf.me> <ada4093ad61814c182f8ca31939962ea@mail.gmail.com> <BDC11A4E-0610-49A3-B8AE-E9D3627B75C8@ajf.me> <eab1ceea2084415d21736a69c4ac6fdc@mail.gmail.com> <53C29EE4.3090808@gmail.com> <63e5b1c38d6e0c5111987e78d9b59be3@mail.gmail.com> <E2926DD2-B0AE-4A87-BEA8-F07FE49CE4B5@ajf.me> <b3026b451453e3c2412bbf45c59f5003@mail.gmail.com> <53C2AF35.40003@gmail.com> <93bb0c689ccca03a0af46c51abf0e11f@mail.gmail.com> <53C2C84A.6060308@garfieldtech.com> <49C63232-AB78-4B2C-A3E4-B21748D5D489@ajf.me>
In-Reply-To: <49C63232-AB78-4B2C-A3E4-B21748D5D489@ajf.me>
Content-Type: text/plain; charset=windows-1252; 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)

On 13/07/2014 19:21, Andrea Faulds wrote:
> On 13 Jul 2014, at 18:56, Larry Garfield <larry@garfieldtech.com> wrote:
>
>> We can discuss when the E_* should be emitted separately from what the cast result is.
> Is there any actual controversy over what the *result* of casts should be. This RFC just has the normal casting result. Is anyone really in disagreement there?

Well, I think the behaviour of ' 42' and '42 ' passed as int could be 
worth reviewing.


>> As long as it's an error of some kind it may be OK, but perhaps we want to leave array as is (strict behavior) rather than changing it to the primitive logic (cast behaviour)?
> I think the discussion about how arrays should be casted too for consistency is a bit silly. What makes sense for non-scalar types (strict hinting) may not work so well for scalar types; casting to array is rarely useful, while casting to the scalar types is readily.

I'm not sure I agree with this. I regularly use foreach( (array)$foo as 
$bar ) for instance - it has the convenient behaviour of looping zero 
times for null, once for a scalar, and leaving an existing array alone.

Objects are definitely a different case, because they have a lot of 
unique behaviour (class hierarchies, additional reference indirection, 
etc). It sometimes makes sense to bundle arrays with objects, in terms 
of "scalar vs non-scalar", but other times it makes more sense to think 
of "simple types (including arrays) vs objects". A mutable, unbounded 
string isn't really "scalar" in the same way as a fixed-size integer, 
anyway.


> Also, frankly, function foobar((int) $a, array $b) is inconsistent and ugly.

Ugly, maybe, but less inconsistent than having function foobar(int $a, 
array $b) { } foobar('a', 'b'); perform a cast to 0 on $a but a fatal 
error for $b.

If there were a mixed syntax, you'd probably be using the cast type for 
both anyway: function foobar((int) $a, (array) $b)

Still, the mixed validate-and-cast approach of this RFC gets around this 
nicely, because there is no "safe cast" to an array available, so no 
case that needs addressing. This doesn't really have to do with it being 
"non-scalar" per se, just that there's no "natural" type-juggling like 
there is for '123' => int or '1.5' => float.

-- 
Rowan Collins
[IMSoP]