Re: PHP proposal on modular systems

If we could just override the require function, so we would be able to mimic the behavior of pytons import, and nodejs’ require. Porting the architecture is rather easy, but without being able to override functions such as require, this is going to be harder. Actually, this is an idea for an RFC i was thinking about… o.o; Thing is just, I dont know how to mod the core to allow overriding of the require function. Kind regards. Am Fr. Feb. 14 2014 13:53:37 schrieb Giuseppe Ronca: > 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. >>> >>> >>