Re: [RFC] Scalar Type Hints

From: Date: Sun, 04 Jan 2015 19:02:29 +0000
Subject: Re: [RFC] Scalar Type Hints
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-80157@lists.php.net to get a copy of this message
2015-01-04 18:31 GMT+01:00 Derick Rethans <derick@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.

« previous php.internals (#80157) next »