> De : Rowan Collins [mailto:rowan.coll...@gmail.com] > > This part is likely to be rather tricky to implement. How do you know if > a 'String' class is defined or not? > > The Engine would have to do something like this: > > - check in-scope use statements for resolutions of 'String' to a > qualified name > - if in namespace scope, try class_exists(__NAMESPACE__ '\String'), > invoking autoloader if registered > - if not in namespace scope, check class_exists('String'), invoking > autoloader if registered > - if class found, hint is an object instanceOf check > - else, hint is a scalar check > > All of this (apart from resolving use statements) has to run *every time > the hint is processed*, since there is no limit on when a class can > become defined. The user has no way of avoiding this penalty, even if > they never intend to declare a String class.
That's right. The transitional phase would introduce a small performance penalty. But that's temporary : as soon as we remove support for bare class names, the runtime overhead and complexity disappears. A simpler, but still acceptable solution, would be just to introduce the 'object' and 'object(Classname)' syntax. Then, we still consider that 'string' is reserved, the compiler recognizes it as a scalar hint, and we tell programmers they must switch their type hints to the new syntax when they conflict with a reserved name. Actually, the message would be that, because of potential conflicts, bare class names are still supported but discouraged and deprecated soon, whatever the class name. We lose the full BC but it may be acceptable for a major version. Then, it can be deprecated in 7.x and suppressed in 8.0. A side effect is that we don't have to reserve names anymore, which will avoid a lot of endless and sterile discussion. It would be simple and quick for prominent frameworks and software to switch to the new syntax, the most important being that they don't have to modify their class names. We can even backport the 'object(classname)' syntax to PHP 5 to make the migration path smoother. If we accept it can still target 7.0, I propose to write an RFC just proposing to add this syntax. I am sorry to insist but we really need to do something. Just look at the suggestion of considering 'string' as the only case-sensitive class name. Are you ready to discuss more and more silly workaround suggestions like this one ? While I am all for making class names case-sensitive (off-topic), distinguishing 'String' from 'string' is definitely a very bad reason ;). I am especially interested by the opinion of Drupal, Wordpress, and other framework developers. Are there any out there ? Please comment. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
