Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77151
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.177 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <CAPRqa+FbfSNb2BDoPj_OoUCdQ_hFzqr3KwDdvLOQ8=ggCsLJ=w@mail.gmail.com>
References: <004d01cfcc63$e7e3ac40$b7ab04c0$@tutteli.ch> <3DB7DEC9-2F99-4DDB-95A9-70455E4BABCB@ajf.me> <54108D63.3070707@gmail.com> <BED6C0F2-C5C7-4ED8-9D4F-1EA5AB93D14A@ajf.me> <CAPRqa+FbfSNb2BDoPj_OoUCdQ_hFzqr3KwDdvLOQ8=ggCsLJ=w@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Thu, 11 Sep 2014 23:00:13 +0100
To: PHP internals <internals@lists.php.net>
Message-ID: <9205aea6-7a4d-4848-8181-a56ecaadc905@email.android.com>
Subject: Re: [PHP-DEV] make casts more strict in PHP 7
From: rowan.collins@gmail.com (Rowan Collins)

On 11 September 2014 04:02:43 GMT+01:00, Park Framework <park.framework@gmail.com> wrote:
>> You know, “int”, “float”, “string” etc. aren’t currently reserved
>words.

Well, they are in the context of casts:

$a = (int)'42';
$a = (string)42;
etc

> We could add functions, or even make them reserved words and add
>internal functions (à la isset), so int(‘2’), float(‘2.0’),
>string(‘test’) etc.

How would this be different from what we already have? For the function version (useful as a callback), we have intval(), strval(), etc

>>
>> Or perhaps class-like constructors? $a = new int('2'); ? Would kinda
>make sense given some people want to add methods to primitive types.
>
>+1
>
>$int     instanceof Int
>$float  instanceof Float
>$num  instanceof Numeric
>$bool  instanceof Boolean
>$str     instanceof String
>$array instanceof Array
>
>This makes it possible not to use the is_*() functions.
>It is desirable to conduct instanceof fully consistent with behavior
>hinting casts, it would be logical and correct.
>Just wanted to be able to use these classes (or interfaces) to create
>their objects, these objects would pass inspection in hinting casts.

This could cause a lot of confusion. If these "constructors" are just a new syntax for type casting, there's no obvious reason to behave differently in terms of strictness, which is what we were discussing previously. Worse, they would look like objects, but behave as plain variables (no reference-like ability to modify the value in place).

Alternatively, these could be special "boxed types", which were real objects acting almost but not quite the same way as the equivalent basic type. Some languages (e.g. Java) have those, but they're frankly rather confusing, and I'm not sure what the benefit would be.

Regards,
-- 
Rowan Collins
[IMSoP]