Hi again, I am not sure this will make it through the noise *sigh* but I'll give a try :)
Derick Rethans wrote: > Hei, > > now some patches by Greg and Dmitry made it into CVS, some of the things > in my mail have been resolved, however, we still need to come up with a > solution to the 1st and most important issue: > > On Tue, 4 Dec 2007, Derick Rethans wrote: > > >> 1. As it is impossible to do "use XXX as NativeClass" we get to the >> point where we'd have to namespace new internal native classes >> otherwise we might introduce BC breaks. AFAIK, we've always said that >> PHP reserves the globals space for it's own use (see also: >> http://www.php.net/manual/en/userlandnaming.rules.php). In case we do >> add new classes (an example could be DateTimeSpan), they should of >> course follow the same format as already existing classes in the >> extension (DateTime, DateTimeZone). However introducing the new class >> DateTimeSpan might break people's code that do things like: >> >> <?php >> use myNamespace::DateTimeZone as DateTimeZone; >> ?> >> >> feature versions of people would then show: >> >> Fatal error: Cannot use myNamespace::DateTimeZone as DomDocument >> because the name is already in use. >> >> It would be silly to require to have to do this: >> >> - Create a class PHP::Date::TimeSpan >> - In your scripts: >> use PHP::Date::TimeSpan >> >> But with the current implementation, this seems to be the only non-BC >> breaking solution. If we chose *not* to require this silly namespacing >> of internal classes, users instead have to do this: >> >> <?php >> use myNamespace::DateTimeZone as myDateTimeZone; >> ?> >> >> Basically prefixing the classnames... This you can already do just >> fine without namespaces. >> > > I know Greg has some ideas with __php__ as recommendation, but I find it > a bit clumsy still. Perhaps Greg can summarize how it will address the > above issue? I've been thinking quite a bit about several suggestions (surprise surprise). First of all, Marcus Boerger suggested on IRC that "__php__" was not the best name, and proposed "__user__" as a more logical choice for the convention, which appeals to me more for the obvious reason that it doesn't have the chance of confusing with "PHP" or "php" should either of these be adopted by the core folks ever. I am going to use some shorthand. "internal class is used first" means this code: <?php namespace hithere; $a = new Exception('hi'); ?> would use ::Exception unles hithere::Exception already exists. In my inimitable style, for the larger suggestions I've been thinking about I will list them: 1) having an implicit namespace for unnamespaced code 2) never accessing internal classes inside a namespace (tough to summarize I explain below) 3) allowing override of internal classes with "use" in the global scope 4) keep things the way they work now, and recommend using "namespace __user__" for userspace code. 1) having an implicit namespace for unnamespaced code This is an interesting idea that will break autoloaders unless the implicit namespace is automatically stripped on a call to autoload, get_class() and reflection. Pros: use myNamespace::DateTimeZone as DateTimeZone; will always work as intended Cons: slight performance hit on every autoload caused by a strstr() check on classname for "__auto__::" and same hit on get_class(), ReflectionClass stuff large number of potential "oops" spots for the implicit namespace to slip into code and break everything horrendously. the patch would be huge and very dangerous for the above reason until kinks are worked out. doesn't solve the "internal class is used first" issue. 2) never accessing internal classes inside a namespace ===================== This basically means changing the autoloading rules to the following (using the hithere namespace/Exception example from above): 1) does hithere::Exception exist? 2) if not, autoload it Pros: it is not necessary to "use hithere::classname" for every class you might autoload. 1 hash lookup reduced per autoloaded class (very minor performance gain, hash lookup is O(1). profiling might not even detect a difference.) Cons: to use internal classes, you would need to explicitly use ::Classname; for each of them. Code that does not use autoload would *also* have to explicitly use ::Classname; code that uses internal classes that wishes to become namespaced would need to go through and figure out which internal classes are used and add "use ::Classname" at the top of the file, making porting to namespaces much more difficult. 3) allowing override of internal classes with "use" in the global scope ===================== This would be surprisingly easy to implement, currently the only thing preventing it from happening is a 5-10 line check in zend_do_use() to see if the name requested would conflict with an internal class. Remove that check and it becomes possible Pros: Derick's main issue goes away, name conflicts with internal classes are never possible when "use"ing them it becomes possible to change which class is used in a file with 1 line of code: <?php use myNamespace::Exception as Exception; ?> As opposed to two: <?php namespace __user__; use myNamespace::Exception as Exception; ?> Cons: It is then possible to accidentally override an internal classname used in the code. it encourages continuing to declare classes/functions in the global namespace, resulting in potential name conflicts a la "Date" -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
