2015-01-04 18:31 GMT+01:00 Derick Rethans <der...@php.net>:
> On Wed, 31 Dec 2014, Stanislav Malyshev wrote:
>
>>
>> The issue is the class names though. E.g. see:
>> https://github.com/ralphschindler/zf2-db/blob/master/research/ColumnType/Integer.php
>
> That's in a namespace, so it's not actually Integer, but
> Zend\Db\Metadata\Type\Integer
It might add some value to forbid importing of unaliased type named
classes via use, so that no ambiguous type annotation exists.
Example:
use My\Lib\string as UserString; // fine, no error
use My\Lib\int; // Compile error: Forbidden to import scalar type. Use
`as` to create an alias
function test (int $a, UserString $b); // what is int?
Most libraries should be able to resolve such issues in a minor
release to stay compatible with PHP 7. If a user doesn't use PHP 7 he
won't be affected as the old import still works and the name of the
class (if namespaced) hasn't changed, if he switches to PHP7 the
updates can probably be automated.
Namespaced classes can still be named whatever they want as the
following(typehint an alias of the own class, using FQN) is already
valid and the signature of the method would not change(no major
release of a library required).:
namspace abc;
use abc\int as MyInt;
class int { function a(MyInt $a, \abc\int $b) ;}
> "PHP owns the top-level namespace but tries to find decent descriptive
> names and avoid any obvious clashes."
I don't think to many people wrap types in a class in the global
namespace. Those people who care about the possible benefits are
likely to use namespaces, pseudo/pear namespaces or more specialized
classes anyway.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
