Hi! > New classes within 7.2 (e.g. \HashContext) to be moved without concern > for BC (e.g. \php\Hash\HashContext) > > Older classes (e.g. \RecursiveIteratorIterator) to be moved AND > ALIASED FOR BC (e.g. \php\SPL\Iterator\RecursiveIteratorIterator)
Do we really need this? I mean, it's not very likely that there's another RecursiveIteratorIterator in PHP code, and in user code it'd be namespaced anyway... It just looks like a lot of moving things around without any visible (at least visible to me) benefit. And given that no code would be able to use the long name for like 10 years, and even then why would anybody use long name if short one works.... In general, I don't see a point. New exts/features - sure. > "Aliasing" could be potentially accomplished in a few ways: > 1. Literally just class_alias(). Put another copy of the > zend_class_entry into the EG(class_table) under a different name. > 2. "Auto-use": Compile-time analysis of classname: "Is it in this list > of BC classes? Implicitly map it." > 3. ...? > > I like #2 because we can raise compile-time deprecation warnings and > we don't introduce any runtime overhead for most cases. > > Obviously, no removal of support for non-namespaced names until AT LEAST PHP > 8.0 > > This two big unanswered questions for me before I'd put this into an RFC are: > 1. How to achieve BC in the best way > 2. What to do about functions/constants? Instinct says move 'em just > like classes. I don't really want \PHP\Core\Constants\E_NOTICE. This looks like annoying parts of Java too much. I mean, namespaces are great, I use them every day, they are super-helpful - but that doesn't mean we should put everything in deep namespaces - especially things that are already quite fine without them. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
