Re: PHP proposal on modular systems

Sorry for "necroposting" but i would bumping this because since package managers such as composer/bower etc. are growing , the hell of dependencies conflicts is increasing proportionally. here you are other examples: http://stackoverflow.com/questions/12656982/resolving-dependency-hell-with-composer http://stackoverflow.com/questions/15256416/symfony2-how-solve-two-bundles-requirements-conflicts-when-using-composer it's a real problem and not always caused by "bad programming". i think that the language itself must offer a solution in this case ( see javascript and no-conflicts techniques ) so , as explained in my first post, namespaces could be a nice solution if they can be nested or dynamically added in some way. 2013-07-17 0:29 GMT+02:00 Giuseppe Ronca <giuseppe.ronca2@gmail.com>: > Sorry , i think you're misunderstanding the main concept of this proposal > .. > > take a look at this post: > http://news.php.net/php.internals/68118 it > explains how you could solve this problem using namespace. > You can actually have 2 version of the same library loaded inside same > process . But namespacing libraries ,using version number encoded in > namespace, is not a common technique...and manually namespacing libraries > is often a long job. > > It could be solved by precedent language features IMHO i've exposed. And > many people can gain on this.. Composer too. > > > 2013/7/16 Giuseppe Ronca <giuseppe.ronca2@gmail.com> > >> You can have multiple objects from the same type in different >>> implemenations in the same process? >>> >> >> >> No i'm not saying it. >> >> >> >>> What should happen, when I instanciate an object of "test" in version X >>> and >>> pass it to a function, that expect it as version Y? To be consistent PHP >>> _must_ trigger an error too, if something from the locally included file >>> leaves its scope >>> >>> class foo { >>> public static function bar () { >>> local_include "test.php" / / file which includes "test" >>> class; >>> return new test (); // <-- error here >>> } >>> } >>> Because else it is not a local scope anymore. >>> >> >> >> the concept as i said is the same of "nesting" a class inside another ( >> or dynamically namespacing a file ) >> >> >> if two different components need "Library v1.0" and "Library v2.0" .. >> they will probably have same classes and namespaces ( but the code is not >> the same ). So how could we use both lib at the same time? Actually php >> can't load classes in a scope way so you can't do it in any way on global >> scope. >> >> nesting dynamically libraries inside a namespace or a class , we can >> create objects that can be accessed only throught their root >> namespace/class...something like: >> >> new Version1\ExternalLibrary\FooClass(); >> >> new Version2\ExternalLibrary\FooClass(); >> >> and also Composer will thankyou about it since they can solve >> automatically problems . >> >> >> >>> Backward compatibility (or compatibility in general) between component is >>> something the plugin maintainer should take care of, not the language. >>> Regards, >>> Sebastian >> >> >> >> i'm talking about backward compatibility of php version...not external >> plugins etc...i think that my idea doesn't require any change to php apps >> to adapt their code. >> >> >