Re: Scalar Type Hints v0.4

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]