François Laupretre wrote on 18/02/2015 15:47:
De : Leigh [mailto:lei...@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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
