Hi François,
> Please give more precise examples. I'm afraid I don't understand :
I try to clarify.
> If you use \ as prefix for builtin types, how do you distinguish this from
> classes ? Would \resource mean the builtin type or a class name ?
Currently, all traits, classes and interfaces share a common symbol
table. So if a trait Foo exists in a namespace bar\, not interface or
class with name Foo can also exist inside that namespace.
I now would not limit this symbol table to hold only the
class/interface/trait names but hold the names of all possible types.
(Types are classes, traits, interfaces, scalar types, arrays, etc)
If the integer type is named "int" in namespace \, that means you can
not define a class/trait/interface/whatever in \ that is also named int.
> Do you mean no class could be defined under \ ?
But any other class can be defined under \ as long as the name does not
conflict with other type names.
> Syntax for union types ?
Union types where mentioned here several types e.g. for the numeric type
that would be defined somewhat like numeric = int|float but without a
specific syntax so far. These union types also look like a hack in the
moment and will get hardcoded somewhere. For each new union type that is
required, another name has to be excluded from being a valid class name.
If all these types also would only go into the \ namespace, there would
be nearly no BC break (at least with namespaced code).
The ability to define union types could even be exposed to the user
space to allow something like this:
namespace Foo;
class MyIncompatibleDateTime { ... }
union DateTime = \DateTime|MyIncompatibleDateTime;
class Whatever {
// Allow \DateTime and \Foo\MyIncompatibleDateTime here
function doWithDate(DateTime $date) { ... }
}
Another case are enum types that I saw on the list some time ago. The
names of the enum types should also go into the same symbol table.
>From the point of view of a consumer/user of the language, it is kind of
inconsistent to have some type names that are limited in their scope
(class/trait/interface names are only valid inside their namespace) and
some type names that are global (primitive types like string/int/etc.).
We could argue now that it would be even better to put all primitive
types inside of \PHP so there would be absolutely no BC break when we
introduce them. We could also make very clean in the docs that users
should never ever define any types inside the \PHP namespace.
I understand that scalar types and classes are something different
inside the engine and I do not propose to remove all scalar types in
favor of class based primitive types. But the handling in the engine and
the resolution of a name in the PHP code are two different things. But
if we can allow scalar type names as type hints or return types, we
should also be able to put the names into the same namespaced symbol
table as we put class names. But I do not have a deep inside in the
inner workings of the engine code so this is only guesswork.
I hope my points are understandable. Thank you for your patience.
Greets
Dennis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
