Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83091
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.45 as permitted sender)
Message-ID: <54E4BEDA.70009@gmail.com>
Date: Wed, 18 Feb 2015 16:33:30 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAESVnVoZYiMWQk1Ydc-9wbkJo7Ru_4mrUtrubW=Rh=QKK9o8TA@mail.gmail.com> <CAPwsocFUF9WcTxc-BjmaCccdPbeYs5VgyDvqYbx=3cR-SwoPkg@mail.gmail.com> <032f01d04b92$2722e0d0$7568a270$@php.net>
In-Reply-To: <032f01d04b92$2722e0d0$7568a270$@php.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Scalar Type Hints v0.4
From: rowan.collins@gmail.com (Rowan Collins)

François Laupretre wrote on 18/02/2015 15:47:
>> De : Leigh [mailto:leight@gmail.com]
>>
>> Can we keep a 0) of "reserve names for future use in-case of RFC
>> failure" option.
> Reserving names is only needed as long as we keep keywords sharing the same naming space as classes. This is a mistake from the past and, as long as we keep it, each new keyword is a pain. Reserving keywords in advance can only lead to reserving too few or too much. So, IMO, deprecating bare class names as hint is first. Then, we can reserve a limited set of keywords.

What if we defined the types as names in the \PHP namespace, but defined 
a slightly different algorithm for resolving typehints vs other uses:

function foo(\PHP\types\numeric $a) // unambiguous but unwieldy
function foo(\My\Namespace\numeric $a) // unambiguously *not* a built-in 
type
function foo(numeric $a) // ambiguous, resolved at compile time

The name would be resolved as follows:

Given a typehint $type:
1) If $type begins with '\PHP\types\', interpret it it as an internal type.
2) ElseIf $type contains '\', interpret it as a class name, and proceed 
with normal class resolution at runtime.
3) ElseIf \PHP\types\$type is the name of a built-in type, interpret it 
as that internal type.
4) Else, interpret it as a class name, and proceed with normal class 
resolution at runtime.

Basically, this means you can do the following:

class String {}
function accept_scalar_string(string $string) { ... }
function accept_string_object(\String $string) { ... }


The nice thing about this is that if we ever allow users to define 
"basic" types - copy-on-write structs, range types, enums, etc - they 
could "extend" these built-in types.


Does that make sense to anyone, or am I over-complicating things?

Regards,
-- 
Rowan Collins
[IMSoP]