Re: [RFC] Scalar Type Hints

Hey Sebastian, > On 4 Jan 2015, at 19:02, Sebastian B.-Hagensen <sbj.ml.read@gmail.com> wrote: > > 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 That’s something that was actually on my todo list. No point in forbidding class names if you can get around it with use. Once I do this in the patch I’ll update the RFC to say as much. > 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. Yes, this is possible. You could just rename the class to something that’s OK in both PHP 5 and 7 (IntClass, e.g.), then add a conditional class_alias() for PHP 5. Actually, I’d need to update class_alias() as well. Hmm. Maybe I should make some sort of internal is_class_name_permitted() function. > 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) ;} I don’t like the idea of allowing these within namespaces, because relative uses would still be broken. Better to just force people to fix their class names. Thanks. -- Andrea Faulds http://ajf.me/