Hey Sebastian,
> On 4 Jan 2015, at 19:02, Sebastian B.-Hagensen <sbj.ml.r...@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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
