# true namespaces, yet another point of view - Thread: https://externals.io/message/40639 - Original archive: https://news-web.php.net/php.internals/40639 - Started by jvlad on 2008-09-23T13:48:44+00:00 - Messages: 17 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #40639 — jvlad — 2008-09-23T13:48:44+00:00 URL: https://externals.io/message/40639#40639 Hello all, May I suggest something in this area? I hope it will resolve some problems related to namespaces and classes ambiguity. Let's first take a look at the classes. In-general they represent two things: scope and data. Scope is a thing that can't be changed without compiler efforts and contains methods and constants. We access these things using :: separator. 2nd thing that I called data obviously contains class instance data that we know under property name. We can change data during runtime and we do it using executor. To access data we normally use -> separator. At this point somebody may want to point me out to the methods (the scope!) accessed with -> too. That's correct. But in this case we always mean $this or $variable that points to the Data, where executor will find pointer to the scope and will access it internally. From this perspective, namespace is nothing more but another layer of scopes. Indeed, it's supposed to contain all things like classes, functions, and even variables. If we make namespaces as power as this, they will be useful in complicated situations when for example you need to work with a 3rd party framework that is full of classes, functions, and global variables with _the_same_ names as the ones you use in your own project. So you need a way to _isolate_ the framework and you need to do it _without_ any modifications in its code or you will have maintain your own changes in the foreign code each time the code is changed. With appropriately powerful namespaces, its just matter of moving all the framework objects (I mean classes, defines, functions, and global variables) into namespace. It comes with its own namespaces? Not a problem (see below). I suggest to remove class table and introduce scope table. This table will contain classes and namespaces. Technically speaking, with this approach namespace may contain other namespaces, classes, variables, defines, and functions. To access scope's item you still use :: separator. It's not that hard to access items at any level without even knowing you access class's scope or namespace's. It does not really matter! You only need to know names of the scopes and their relationship. There is always current scope, which is "global" or noname namespace by default. It's created before any other items such as embedded functions or classes are created. If you have thing1::thing2 in your code, executor should first lookup current scope for thing1 and if not found, lookup in the global namespace (unless current is global). You see, it does not really matter if thing1 is a class or namespace. It's just a scope name to lookup for and once namespaces and classes are all in one hash, it's quite trivial to do. Include, require and their "_once" brothers, should include the file and make all its objects (like classes, functions, global variables) to be created in the current namespace. So the isolation will be achieved easily, you simply put include into a namespace and all the rest, including nested includes, will put all thing into the namespace. namespace isolated_space { include "3rdpartyframework/library.inc"; } There is one more difference between namespaces and classes. You can span a namespace across multiple files and have multiple chunks of the same namespace in one. With "include" sample above, to access functions or classes, we'll use either way: 1. reopen namespace and make call from it: namespace isolated_space { afuntioncall(); } 2. specify the namespace explicitly: isolated_space::afunctioncall(); In both cases, current namespace will be swithched to isolated_space and all things accessed by afunctioncall() will be looked up for in this namespace first. Think about namespaces like directories in the filesystem. You can specify relative and absolute path. All other items like files, symlinks, devices, etc have to exist in directories. -jv --- ## #40646 — Kevin Waterson — 2008-09-23T20:57:41+00:00 URL: https://externals.io/message/40639#40646 · In reply to: #40639 This one time, at band camp, "jvlad" wrote: > May I suggest something in this area? May I suggest something also.. Lets just let namespaces die and let it become a repressed memory as it seems it is more trouble that it is worth. Seriously. For 10+ years we have got on just fine without them, and the amount of work to get a second-best implementation that nobody agrees on hardly seems benificial. The gains of namespaces are minimal at best, because a few cannot be bothered with some simple prefixing. PHP 5.3 release is looming, and there is STILL conflict about implementation. The current approach is a long way from what was thought of as namespace support and it seems nobody is completely happy with any model that has been put forward. The current implementation is nothing but a series of comprimses, each one taking away a little of the functionality that was first envisaged. Lets just let it die. It is un-needed, un-wanted by many, and the end result seems to be less that optimal, or even a true implementation of namespaces. Kevin --- ## #40648 — Jochem Maas — 2008-09-23T21:38:18+00:00 URL: https://externals.io/message/40639#40648 · In reply to: #40646 [[@devs: nothing of technical importance in this email, but it might make you feel better :-) ... even Stas!]] Kevin Waterson schreef: > This one time, at band camp, "jvlad" wrote: > everything that jvlad wrote was way too vague for me to understand so I couldn't possibly comment on it. > > > […] > > May I suggest something also.. Lets just let namespaces die and let > it become a repressed memory as it seems it is more trouble that it > is worth. Seriously. why does the ammount of trouble other people take upon themselves matter to you? ... and "repressing memory" is very bad advice (but that's rather esoteric). > For 10+ years we have got on just fine without them, and the amount > of work to get a second-best implementation that nobody agrees on > hardly seems benificial. The gains of namespaces are minimal at best, > because a few cannot be bothered with some simple prefixing. the gains are in the eye of the beholder, beyond the issue of symbol name collision avoidance there is big a real issue with very_very_very_very_very_very_very_very_looooooooooong_symbol_names ... it's a proven fact it becomes increasingly more difficult to grok lines of code as they increase in length ... namespaces offer a mechanism to mitigate overly long lines (at the cost of some obsfucation). you may decide the gains are minimal and not worth pursuing personally, but plenty of others feel the exact opposite. I'm personally a little ambivelent regard to inhouse code but I do envisage that libs like PEAR and ZF will become much more appealing when they take on namespaces, as such I care about whatever it [namespaces] becomes being 'good' .. because either way, sooner or later, I will be confronted with using them even if I don't use them in code I write myself. (my stance makes sense to me but It's likely I'm not expressing it very well!) > PHP 5.3 release is looming, and there is STILL conflict about implementation. 1. conflict is everywhere, even outside of the world of php functionality implementations. 2. that 5.3 is 'looming' has surely not escaped the RMs 3. shouldn't 5.3 be release when it's ready rather because people expect it to be? > The current approach is a long way from what was thought of as namespace > support and it seems nobody is completely happy with any model that > has been put forward. what exactly was thought of as namespace support? whatever it is exactly it is apparent that's it's wide open to mis-interpretation ... this is something to be tackled with documentation. I don't think the 'model' has been under attack, rather a number of ambiguity issues which were not fully foreseen ... issues which I might add are due in no small part to the 10+ years of baggage php has collected. it's easy to throw out the word 'namespaces' and assume everyone is on the exact same page ... it's rather harder to actually build something people are willing to call 'namespaces' ... the fact that it is hard and that the discussions have been long and difficult do not of themselves mean the effort and the impending result are not worthwhile. > The current implementation is nothing but a series > of comprimses, actually there has been very little comprise, that's one of the things the lead developer has been taking lots of flak for. > each one taking away a little of the functionality that > was first envisaged. the only thing that has been proposed to be taken away is functions and constants ... both of which can be incorporated at a later date (without the stress of release deadlines and having to deal with additional BC issues, imho), I personally think a phased introduction of namespacing functionality is not a bad thing, granted getting everything in one go would be nicer but at the end of the day you can't shoot yourself in the foot with a gun you don't have. the other major issue revolved around name resolution order upon which consensus has been reached in fact AFAICT (I've read everything that's been written AFAIK). > Lets just let it die. It is un-needed, un-wanted by many, and the end > result seems to be less that optimal, or even a true implementation > of namespaces. I would offer that bandying about subjective opinions as to what is wanted, what is true, etc, etc as being objective fact is one of the things that needs to die more than anything else. php counts it's user's in the 100,000's if not 1,000,000's ... I'd hazard to say that it's nigh on impossible to get accurate stats regarding namespace support. rgds, Jochem --- ## #40650 — Steph Fox — 2008-09-23T23:10:12+00:00 URL: https://externals.io/message/40639#40650 · In reply to: #40646 > Lets just let it die. It is un-needed, un-wanted by many, and the end > result seems to be less that optimal, or even a true implementation > of namespaces. Oddly enough, I agree with Kevin with my heart and soul. But then I hear the howls of outrage from the Other Side, who campaigned without ruth to get namespaces into PHP in the first place. Would someone with authority (Andi? Derick?) like to give an overview of the pros, cons and issues at this point? It's quite difficult to follow all these tiny, endless myco-esque threads, and I share Greg's allergy to wikis for the simple reason that the model is similar. Each item sparks another. - Steph --- ## #40651 — Guilherme Blanco — 2008-09-23T23:17:17+00:00 URL: https://externals.io/message/40639#40651 · In reply to: #40650 For those that do not understand very well the explanation of jvlad... He's suggesting to change the class struct to be an scope struct, and have a property that tells if it's a namespace or a class, and reuse the implementation of class which already works very well. The nested support is achieved afai understand through the Adjacency List algorithm... can you confirm this to me? Just trying to be more clear to those that do not understand... if my words are greek now.... GIYF (Google Is Your Friend). Cheers, > > […] > > Oddly enough, I agree with Kevin with my heart and soul. But then I hear the > howls of outrage from the Other Side, who campaigned without ruth to get > namespaces into PHP in the first place. > > Would someone with authority (Andi? Derick?) like to give an overview of the > pros, cons and issues at this point? It's quite difficult to follow all > these tiny, endless myco-esque threads, and I share Greg's allergy to wikis > for the simple reason that the model is similar. Each item sparks another. > > - Steph > > -- > > > > -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9166-6902 MSN: guilhermeblanco@hotmail.com URL: http://blog.bisna.com Rio de Janeiro - RJ/Brazil --- ## #40652 — Steph Fox — 2008-09-23T23:31:33+00:00 URL: https://externals.io/message/40639#40652 · In reply to: #40651 > For those that do not understand very well the explanation of jvlad... Guileherme, you are missing the point. We'd all like to see PHP 5.3.0 out there. It has a lot to offer, but namespace support is very obviously problematic. That's it, that's all. - Steph --- ## #40653 — Guilherme Blanco — 2008-09-23T23:31:34+00:00 URL: https://externals.io/message/40639#40653 · In reply to: #40652 Steph... I think you should not tell me this... =) I already know it and heard (like you) 5,451,741,709,125 times. Cya, > > […] > > Guileherme, you are missing the point. We'd all like to see PHP 5.3.0 out > there. It has a lot to offer, but namespace support is very obviously > problematic. That's it, that's all. > > - Steph > > -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9166-6902 MSN: guilhermeblanco@hotmail.com URL: http://blog.bisna.com Rio de Janeiro - RJ/Brazil --- ## #40654 — Ryan Panning — 2008-09-24T00:20:42+00:00 URL: https://externals.io/message/40639#40654 · In reply to: #40650 Steph Fox wrote: > > […] > > Oddly enough, I agree with Kevin with my heart and soul. But then I hear > the howls of outrage from the Other Side, who campaigned without ruth to > get namespaces into PHP in the first place. > > Would someone with authority (Andi? Derick?) like to give an overview of > the pros, cons and issues at this point? It's quite difficult to follow > all these tiny, endless myco-esque threads, and I share Greg's allergy > to wikis for the simple reason that the model is similar. Each item > sparks another. > > - Steph Sorry to clutter the list with yet another post but I am starting to second this feeling. As someone who has already started developing with the 5.3 branch and using namespaces, all this discussion is turning me away. There are so many issues still at this point, how can they possibly be resolved in reasonable amount of time for a 5.3 release? (sigh) I'd rather remove what namespacing I've started already and wait for a solid state, then have to change code later and have to deal with multiple possibilities. I have my opinions how I would use namespaces but have not really voiced them just because there has been way to much discussion. There should be a better way to voice opinions than this madness. IMO :) --- ## #40658 — Arvids Godjuks — 2008-09-24T07:06:18+00:00 URL: https://externals.io/message/40639#40658 · In reply to: #40654 I completely agree with jvlad's thoughts - for me namespace is ability to separate two different libraries from each other so that they don't conflict. I don't need namespaces just to write my own application using them to be cool, and I probably would never use a namespace for small or middle size application, but what I will surely do - namespace libraries witch I will use in my application, so that I don't have to use prefixes for my application functions and classes. AndIMHO, I _really_ _don't_ _want_ to remember those complicated rules for name resolution, importing namespaces. There is category of developers, witch will make a real mess of this. As I personally see namespaces: index.php addHandler('loader', $loader); $application->addHandler('db', $db); $application->addHandler('pdf', $pdf); $application->run(); $application->quit(); ?> Of course that isn't a good example, because Zend framework always has a class prefix "Zend", but they surely can use a namespace and remove that Zend in front of classes. And I don't see any point in "use NamespaceName as OtherName" - I open a project, there is namespace Foo used for libraries. Then I open some modules - there is Bar::get() in the code. What will I look for? Namespace Bar, especialy when many namespaces are used in application. imporing foo as bar is quite confusing. Yes, we programmers can handle such things, we can learn from our mistakes, but that's not the reason to make us masochist! I'm fed-up with teaching people all the time how to properly code in PHP or clean the code after such people. Really, sometimes PHP core developers should say to comunity "f*k you, we will do that the proper way" and just do. People are happy with Java, .NET and so on and nobody is complaining that they can't import namespace under other name than original (maybe in some languages you can do that, but I don't code much in other languages, so I can't say that for sure). This is called "standarts" - everybody knows that name "Foo" always means "Foo" if "Foo" package is used in application, and that nobody can import it as "Blah" - they will have to change the namespace in package itself and that's so stupid , that nobody will do that (well if they do - don't mess with such people at all). --- ## #40659 — Lupus Michaelis — 2008-09-24T07:43:35+00:00 URL: https://externals.io/message/40639#40659 · In reply to: #40658 Arvids Godjuks a écrit : > Of course that isn't a good example, because Zend framework always has a > class prefix "Zend", but they surely can use a namespace and remove that > Zend in front of classes. They are a lot of case where you want to use this syntax. The most common is when you have a depth namespace like a russian puppy : namespace org::w3::xhtml::strict as x ; The other reason is to use it for testing purposes, when you develop a new engine, that share the same API with the previous : // namespace org::w3::xml as xml ; namespace com::lupusmic::xml as xml ; But maybe it isn't a good use... :D Namespaces can be a usefull tool, but if wouldn't, don't use. And if it becomes mandatory, fork your own PHP version :D -- Mickaël Wolff aka Lupus Michaelis http://lupusmic.org --- ## #40668 — jvlad — 2008-09-24T14:32:43+00:00 URL: https://externals.io/message/40639#40668 · In reply to: #40651 ""Guilherme Blanco"" wrote in message news:bcb7aa500809231617y3305b5bcn18f47630a8124e0d@mail.gmail.com... > For those that do not understand very well the explanation of jvlad... > > He's suggesting to change the class struct to be an scope struct, and > have a property that tells if it's a namespace or a class, and reuse > the implementation of class which already works very well. > The nested support is achieved afai understand through the Adjacency > List algorithm... can you confirm this to me? > > Just trying to be more clear to those that do not understand... if my > words are greek now.... GIYF (Google Is Your Friend). > Yep. Thanks Guilherme for such a short explanation. (sorry my english is quite poor and not always clear enough) Namespaces create ambiguity with classes in php (which is a dynamic language btw) just because their natures are very close. Beside the other great things, class is intended to isolate its methods and properties, or group them together. Namespace is mostly for the same purposes. It should isolate classes as well as all other user-land entities or group them together. From the end-user perspectives, in most cases it does not really matter if a particular value is stored as a static property of a class or as a global variable in a namespace. Same goes for the static method of a class vs function in the namespace. What's important is to know the scope name. If user uses a variable myentity::$var, it's safficient to lookup for myentity sub-scope in the current scope, then lookup for $var in the found (or just created) sub-scope. You see, it's not always needed to distinguish classes vs namespaces. In some cases the namespace can be resolved in the compile-time. For example if the namespace is already defined, so it's known to be namespace and therefore compiler should be smart enough to make early binding. For the cases when namespace is referenced in the script beforehand, so it's not known whether it is a namespace or a class, it can be resolved with late-binding, using absolutely the same technique as php uses for for resolving the classes. I'm sure this is an efficient way of implementing namespaces in php and with this implementation they will be very useful. jv --- ## #40669 — jvlad — 2008-09-24T14:42:01+00:00 URL: https://externals.io/message/40639#40669 · In reply to: #40652 ""Steph Fox"" wrote in message news:004401c91dd4$85907940$3ffc1f3e@foxbox... > > […] > > Guileherme, you are missing the point. We'd all like to see PHP 5.3.0 out > there. It has a lot to offer, but namespace support is very obviously > problematic. That's it, that's all. > > - Steph > Steph, Maybe I'm just missing the idea... to me it looks an attempt to advertize something that does not even exist. Do you think semi-working namespaces with limited support, that does not go beyound classes, will be greatly appreciated by php developers? What if anything can be solved or achieved with namespaces like offered in 5.3alpha? -jv --- ## #40682 — Lukas Kahwe Smith — 2008-09-25T14:04:34+00:00 URL: https://externals.io/message/40639#40682 · In reply to: #40651 > For those that do not understand very well the explanation of jvlad... > > He's suggesting to change the class struct to be an scope struct, and > have a property that tells if it's a namespace or a class, and reuse > the implementation of class which already works very well. > The nested support is achieved afai understand through the Adjacency > List algorithm... can you confirm this to me? or just leave the organization of things to classes (with long class names with a nice prefix to prevent collissions) and leave it to `class_alias()` (and equivalent features for functions .. also with the option of a compile time aliasing) to handle the aliasing. this removes the need for namespaces and use statements, while making it possible to make class/function names short (that are long for organizational and collision prevention reasons). regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #40687 — jvlad — 2008-09-25T17:09:08+00:00 URL: https://externals.io/message/40639#40687 · In reply to: #40682 > > or just leave the organization of things to classes (with long class > names with a nice prefix to prevent collissions) and leave it to > `class_alias()` (and equivalent features for functions .. also with the > option of a compile time aliasing) to handle the aliasing. > > this removes the need for namespaces and use statements, while making it > possible to make class/function names short (that are long for > organizational and collision prevention reasons). > > regards, > Lukas Kahwe Smith > > No, you can't use classes for this. They can't contain the other classes and you can't have a class spanned across several files. There are some other important differences from the compiler perspecives, but still namespaces and classes are containers and you can access their members with exactly the same syntax constructs so it's not only possible but reasonable to implement them very close to each other, as I suggested in one hashtable. As a side effect it will remove the problem with class vs namespace ambiguity. JV --- ## #40745 — Gregory Beaver — 2008-09-28T22:21:39+00:00 URL: https://externals.io/message/40639#40745 · In reply to: #40682 Lukas Kahwe Smith wrote: > > > > > […] > > > or just leave the organization of things to classes (with long class > names with a nice prefix to prevent collissions) and leave it to > `class_alias()` (and equivalent features for functions .. also with the > option of a compile time aliasing) to handle the aliasing. > > this removes the need for namespaces and use statements, while making it > possible to make class/function names short (that are long for > organizational and collision prevention reasons). Hi, This approach doesn't work because aliasing with `class_alias()` does not allow name conflicts: results in: Warning: Cannot redeclare class XMLReader in /home/cellog/workspace/php5/test.php on line 4 whereas: results in: hi Greg --- ## #40753 — Lukas Kahwe Smith — 2008-09-29T06:13:02+00:00 URL: https://externals.io/message/40639#40753 · In reply to: #40745 > Lukas Kahwe Smith wrote: > > […] > > Hi, > > This approach doesn't work because aliasing with `class_alias()` does > not > allow name conflicts: Well my point was .. Library code uses long names, glue code can alias. Of course sometimes the lines between what is library and glue code are hard to draw. Anyways, I guess we are close to a good solution for namespaces in 5.3 .. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #40794 — jvlad — 2008-09-29T18:58:21+00:00 URL: https://externals.io/message/40639#40794 · In reply to: #40745 > > […] > > Hi, > > This approach doesn't work because aliasing with `class_alias()` does not > allow name conflicts: > > class foo { > function __construct(){echo 'hi',"\n";}} > class_alias('foo', 'XMLReader'); > $a = new XMLReader; > ?> > > results in: > > Warning: Cannot redeclare class XMLReader in > /home/cellog/workspace/php5/test.php on line 4 > >class foo { >function __construct(){echo 'hi',"\n";}} >use ::foo as XMLReader; >$a = new XMLReader; >?> > >results in: > >hi I'm sorry I don't see anything related to namespaces in the sample. It looks like just a trick that allows to bypass restrictions imposed on `class_alias()`. If you need to provide a clear way on creating your very own XMLReader class in the global namespace, while the class with the same name is already registered by an extension, why not to create remove_class()/unregister_class() and/or replace_class() functions which will legitimate class removal/overriding? Still not sure if it's needed at all. With namespaces, you can create your own little world inside your private namespace and have as many overrided classes as you want. Why bother with global namespace?