# PHP proposal on modular systems - Thread: https://externals.io/message/68115 - Original archive: https://news-web.php.net/php.internals/68115 - Started by Giuseppe Ronca on 2013-07-14T10:13:48+00:00 - Messages: 20 - 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 --- ## #68115 — Giuseppe Ronca — 2013-07-14T10:13:48+00:00 URL: https://externals.io/message/68115#68115 Php is now used by many CMS, many of which use a modular system with a wide range of add-ons developed by third parties. This can cause various conflicts, such as when two or more external components using the same library (i.g. with a different version) in this case the classes / namespace will be in collision. This can become unmanageable by the webmaster because they are not always able to change third parties code and there aren't other "clean" methods to solve this kind of problem ( complex and dirty eval methods excluded ). here you are a thread related to this issue: http://stackoverflow.com/questions/17628475/php-include-different-version-of-same-library *One possible solution* would be to extend the scoping for the inclusions of files using something like:* local_include_** in this way you can also create a sort of "nesting" system for classes making possible a syntax like this: class foo { public static function bar () { local_include "test.php" / / file which includes "test" class; return new test (); } } echo get_class (foo :: bar ()) / / output: "test" new test () / / raise an error instead *Also this could work:* namespace {oldversion local_include / lib/api-1.0/library.php; } namespace {newversion local_include / lib/api-2.0/library.php; } $ oldlibary = new oldversion \ Library (); $ newlibrary = new newversion \ Library (); It shouldn't have backward compatibility issues since it's a new implementation and you shouldn't change anything else. What do you think about that? --- ## #68114 — Giuseppe Ronca — 2013-07-14T10:21:15+00:00 URL: https://externals.io/message/68115#68114 · In reply to: #68115 sorry about code formatting mistakes..* **namespace {newversion* must be *namespace newversion {* of course 2013/7/14 Giuseppe Ronca > Php is now used by many CMS, many of which use a modular system with a > wide range of add-ons developed by third parties. This can cause various > conflicts, such as when two or more external components using the same > library (i.g. with a different version) in this case the classes / > namespace will be in collision. This can become unmanageable by the > webmaster because they are not always able to change third parties code and > there aren't other "clean" methods to solve this kind of problem ( complex > and dirty eval methods excluded ). > > here you are a thread related to this issue: > http://stackoverflow.com/questions/17628475/php-include-different-version-of-same-library > > *One possible solution* would be to extend the scoping for the inclusions > of files using something like:* local_include_** > > in this way you can also create a sort of "nesting" system for classes > making possible a syntax like this: > > class foo { > public static function bar () { > local_include "test.php" / / file which includes "test" class; > return new test (); > } > } > > echo get_class (foo :: bar ()) / / output: "test" > > new test () / / raise an error instead > > > *Also this could work:* > > namespace {oldversion > local_include / lib/api-1.0/library.php; > } > namespace {newversion > local_include / lib/api-2.0/library.php; > } > > $ oldlibary = new oldversion \ Library (); > $ newlibrary = new newversion \ Library (); > > It shouldn't have backward compatibility issues since it's a new > implementation and you shouldn't change anything else. > What do you think about that? --- ## #68116 — Sebastian Krebs — 2013-07-14T10:39:18+00:00 URL: https://externals.io/message/68115#68116 · In reply to: #68115 2013/7/14 Giuseppe Ronca > Php is now used by many CMS, many of which use a modular system with a wide > range of add-ons developed by third parties. This can cause various > conflicts, such as when two or more external components using the same > library (i.g. with a different version) in this case the classes / > namespace will be in collision. This can become unmanageable by the > webmaster because they are not always able to change third parties code and > there aren't other "clean" methods to solve this kind of problem ( complex > and dirty eval methods excluded ). > > here you are a thread related to this issue: > > http://stackoverflow.com/questions/17628475/php-include-different-version-of-same-library > > *One possible solution* would be to extend the scoping for the inclusions > of files using something like:* local_include_** > > in this way you can also create a sort of "nesting" system for classes > making possible a syntax like this: > > class foo { > public static function bar () { > local_include "test.php" / / file which includes "test" class; > return new test (); > } > } > > echo get_class (foo :: bar ()) / / output: "test" > > new test () / / raise an error instead > > > *Also this could work:* > > namespace {oldversion > local_include / lib/api-1.0/library.php; > } > namespace {newversion > local_include / lib/api-2.0/library.php; > } > > $ oldlibary = new oldversion \ Library (); > $ newlibrary = new newversion \ Library (); > > It shouldn't have backward compatibility issues since it's a new > implementation and you shouldn't change anything else. > What do you think about that? > You can have multiple objects from the same type in different implemenations in the same process? 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. Backward compatibility (or compatibility in general) between component is something the plugin maintainer should take care of, not the language. Regards, Sebastian -- github.com/KingCrunch --- ## #68117 — johannes@schlueters.de — 2013-07-15T09:14:43+00:00 URL: https://externals.io/message/68115#68117 · In reply to: #68116 > > Backward compatibility (or compatibility in general) between component > is something the plugin maintainer should take care of, not the > language. Ack. If a library becomes incompatible one should change the name or namespace or something. Besides the pure compatibility issue "traditionally" we also had a distribution problem in PHP - if a module requires a generic library either the library had to be bundled or the user had to be sent for a hunt and manually do it, which became complicated if there are further dependencies and different libraries have the same dependencies ... for that Composer is a quite good solution which does a great job in handling projects and its dependencies. johannes --- ## #68118 — Sebastian Bergmann — 2013-07-15T10:07:55+00:00 URL: https://externals.io/message/68115#68118 · In reply to: #68117 Am 15.07.2013 11:14, schrieb Johannes Schlüter: > Besides the pure compatibility issue "traditionally" we also had a > distribution problem in PHP - if a module requires a generic library > either the library had to be bundled or the user had to be sent for a > hunt and manually do it, which became complicated if there are further > dependencies and different libraries have the same dependencies ... for > that Composer is a quite good solution which > does a great job in handling projects and its dependencies. The original poster described a situation where an application uses component A and component B each of which depend on different versions of component C. Unless I missed a corresponding feature so far, Composer does not solve this problem. This problem could be solved, however, by encoding the version number in the namespace name: namespace vendor\component\v100 { class foo {} } namespace vendor\component\v110 { class foo {} } This would allow the usage of two versions of a component inside the same PHP process. -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ --- ## #68119 — johannes@schlueters.de — 2013-07-15T10:43:43+00:00 URL: https://externals.io/message/68115#68119 · In reply to: #68118 > > Unless I missed a corresponding feature so far, Composer does not > solve > this problem. This problem could be solved, however, by encoding the > version number in the namespace name: I didn't say composer solves that part, for that part I said Ack. If a library becomes incompatible one should change the name or namespace or something. But composer solves many of the other issues around the use of libraries. imo being *the* enabler to really manage reusable components, even when as small and as simple as a logger interface ... which was a pain in "the old days" .... johannes --- ## #68120 — Florin Patan — 2013-07-15T13:19:11+00:00 URL: https://externals.io/message/68115#68120 · In reply to: #68115 On Sun, Jul 14, 2013 at 12:13 PM, Giuseppe Ronca wrote: > Php is now used by many CMS, many of which use a modular system with a wide > range of add-ons developed by third parties. This can cause various > conflicts, such as when two or more external components using the same > library (i.g. with a different version) in this case the classes / > namespace will be in collision. This can become unmanageable by the > webmaster because they are not always able to change third parties code and > there aren't other "clean" methods to solve this kind of problem ( complex > and dirty eval methods excluded ). > > here you are a thread related to this issue: > http://stackoverflow.com/questions/17628475/php-include-different-version-of-same-library > > *One possible solution* would be to extend the scoping for the inclusions > of files using something like:* local_include_** > > in this way you can also create a sort of "nesting" system for classes > making possible a syntax like this: > > class foo { > public static function bar () { > local_include "test.php" / / file which includes "test" class; > return new test (); > } > } > > echo get_class (foo :: bar ()) / / output: "test" > > new test () / / raise an error instead > > > *Also this could work:* > > namespace {oldversion > local_include / lib/api-1.0/library.php; > } > namespace {newversion > local_include / lib/api-2.0/library.php; > } > > $ oldlibary = new oldversion \ Library (); > $ newlibrary = new newversion \ Library (); > > It shouldn't have backward compatibility issues since it's a new > implementation and you shouldn't change anything else. > What do you think about that? Hello, I've had the following problem about two weeks ago... Environment used: Symfony2 app + Composer + : - I was using version 0.2-dev of a certain library - the app was using 0.1.x of the library. Unfortunately v0.2 decided to change some of the configuration properties, and a couple of classes, all not documented. What would happen in this case if PHP would have a versioning system for the modules/libraries? How would Symfony2 be able to cope with that? Jumping from Symfony2 to any other script out there, how will this change affect the other applications out there? The way I'd see this would be to include the notion of global libraries to Composer, with versioning and so on. Then, once people get used to this concept, move Composer to PHP (not necessarily in C), just like GO has 'go get' for example, or Python pip. Best regards, Florin ---- Florin Patan https://github.com/dlsniper http://www.linkedin.com/in/florinpatan --- ## #68121 — Giuseppe Ronca — 2013-07-15T14:51:22+00:00 URL: https://externals.io/message/68115#68121 ---------- Forwarded message ---------- From: Giuseppe Ronca Date: 2013/7/15 Subject: Re: [PHP-DEV] PHP proposal on modular systems To: Johannes Schlüter I'm not talking about this kind of problem... I think you know how a CMS works ... we've for example : * *CMS sources that are developed by Joomla devs ( i.g ) with theirs libraries.* * *Plugin (A) developed externally and installed by the final user, that includes inside its sources pclzip library ( the version and library doesn't matter) .* * *Component (B) developed externally and installed by the final user, that includes inside its sources pclzip library again.* Now ..since that library could not be installed in CMS by default, since devs of the Plugin (A) can't know if needed library is installed ( at their needed version ) inside another component...*we will have ofc a name collision when both plugin and component will be loaded.* It could be also a problem of various languages...but classes in local scope / nested are a known technique used by different languages..and php could implements it even better. In this way any CMS/Extension can arbitrary decide to use load their components/library in a private scope ( avoiding collision ) . i.g: class Loader { public static function LoadComponent () { local_include "foo_component/loader.php"; } } PS i'm not so practice with composer ( used few times ) but when modular systems , such as CMS , give the possibility to extends them with external components...i don't think that composer could solve this problem. 2013/7/15 Johannes Schlüter > > > […] > > Ack. If a library becomes incompatible one should change the name or > namespace or something. > > Besides the pure compatibility issue "traditionally" we also had a > distribution problem in PHP - if a module requires a generic library > either the library had to be bundled or the user had to be sent for a > hunt and manually do it, which became complicated if there are further > dependencies and different libraries have the same dependencies ... for > that Composer is a quite good solution which > does a great job in handling projects and its dependencies. > > johannes --- ## #68122 — Marco Pivetta — 2013-07-15T15:06:35+00:00 URL: https://externals.io/message/68115#68122 · In reply to: #68121 > I'm not talking about this kind of problem... > I think you know how a CMS works ... we've for example : > > * *CMS sources that are developed by Joomla devs ( i.g ) with theirs > libraries.* > * *Plugin (A) developed externally and installed by the final user, that > includes inside its sources pclzip library ( the version and library > doesn't matter) .* > * *Component (B) developed externally and installed by the final user, that > includes inside its sources pclzip library again.* > That's why you got two names for a different implementation of the same thing. You can't call your own thing the same as the original one: it's not the same. That would even confuse the consumer, which doesn't know if it's the original or the new one. > > Now ..since that library could not be installed in CMS by default, since > devs of the Plugin (A) can't know if needed library is installed ( at their > needed version ) inside another component...*we will have ofc a name > collision when both plugin and component will be loaded.* > That's actually one of the problems solved by composer... > It could be also a problem of various languages...but classes in local > scope / nested are a known technique used by different languages..and php > could implements it even better. > These classes still live under their own package, and their fully qualified name is different from all others. > In this way any CMS/Extension can arbitrary decide to use load their > components/library in a private scope ( avoiding collision ) . > i.g: > > class Loader { > public static function LoadComponent () { > local_include "foo_component/loader.php"; > } > } > This is really coupled to your own system and with how extensible you design it. You may look at modern PHP frameworks to see how the problem of extensibility is solved: it's mainly a DI/configuration issue that has nothing to do with class names. PS i'm not so practice with composer ( used few times ) but when modular > systems , such as CMS , give the possibility to extends them with external > components...i don't think that composer could solve this problem. > It is actually already happening. You should really really really check it out before going further in exploring already explored grounds. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ --- ## #68123 — Lester Caine — 2013-07-15T16:24:39+00:00 URL: https://externals.io/message/68115#68123 · In reply to: #68122 Marco Pivetta wrote: > PS i'm not so practice with composer ( used few times ) but when modular > > […] > It is actually already happening. > You should really really really check it out before going further in > exploring already explored grounds. The real problem here is with PEAR being installed as part of the distribution, and not then being compatible with other applications. The safest way to use this is by bundling the correct version with the application, but that does create bigger downloads. Even were applications using the like of Zend framework need the correct version given the number of wrapper systems that go with it. Composer is just another complication that has to be added to the mix ... and not currently common in linux distributions? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #68124 — Ralf Lang — 2013-07-15T17:42:04+00:00 URL: https://externals.io/message/68115#68124 · In reply to: #68123 Am 15.07.2013 18:24, schrieb Lester Caine: > Marco Pivetta wrote: > > […] > > The real problem here is with PEAR being installed as part of the > distribution, and not then being compatible with other applications. The > safest way to use this is by bundling the correct version with the > application, but that does create bigger downloads. Even were > applications using the like of Zend framework need the correct version > given the number of wrapper systems that go with it. > > Composer is just another complication that has to be added to the mix > ... and not currently common in linux distributions? > Most distributions I know package their RPM/deb based on pear releases. I'm not a big fan of bundling a fixed set of bugs or bugfix releases of loosely related libs with an app (rubygem style) and having them twice or more times on a given system. Composer still has its place. I don't see much to do here for php core. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 --- ## #68125 — Sebastian Krebs — 2013-07-15T21:30:07+00:00 URL: https://externals.io/message/68115#68125 · In reply to: #68123 2013/7/15 Lester Caine > Marco Pivetta wrote: > > > […] > > The real problem here is with PEAR being installed as part of the > distribution, and not then being compatible with other applications. The > safest way to use this is by bundling the correct version with the > application, but that does create bigger downloads. Even were applications > using the like of Zend framework need the correct version given the number > of wrapper systems that go with it. > > Composer is just another complication that has to be added to the mix ... > and not currently common in linux distributions? No need for: $ chmod +x composer.phar $ # use it > > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/wiki/?page=**contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk > Rainbow Digital Media - http://rainbowdigitalmedia.co.**uk > > > -- > > > > -- github.com/KingCrunch --- ## #68126 — Giuseppe Ronca — 2013-07-15T22:31:11+00:00 URL: https://externals.io/message/68115#68126 · In reply to: #68122 I've studied Composer and as i thought ..it's a "component installer" (implementing an autoload system) .. nothing else ( i can have similar result using git submodules ) anyway , *you can have a class collision using or not using composer ( it doesn't solve it, but just advise you that you can't install that package )* for example, if i require those packages ( that require respectively monolog 1.3 and monolog 1.2 ) : { "require": { "dbarbar/campfire-monolog-handler": "dev-master", "swestcott/monolog-extension": "dev-master" } } *composer will shows it:* - Can only install one of: monolog/monolog[1.3.0, 1.2.0]. - Can only install one of: monolog/monolog[1.3.0, 1.2.1]. - *Conclusion: don't install monolog/monolog 1.3.1 * so , since both of packages need same library ( but with different version ) you can't install them. It's the same limitation that you can find in CMS and external extensions ...and it's a language issue ofc. 2013/7/15 Marco Pivetta > > > > > […] > > That's why you got two names for a different implementation of the same > thing. > You can't call your own thing the same as the original one: it's not the > same. > That would even confuse the consumer, which doesn't know if it's the > original or the new one. > > > > […] > > That's actually one of the problems solved by composer... > > > > […] > > These classes still live under their own package, and their fully > qualified name is different from all others. > > > > […] > > This is really coupled to your own system and with how extensible you > design it. > You may look at modern PHP frameworks to see how the problem of > extensibility is solved: it's mainly a DI/configuration issue that has > nothing to do with class names. > > PS i'm not so practice with composer ( used few times ) but when modular > > […] > > It is actually already happening. > You should really really really check it out before going further in > exploring already explored grounds. > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ --- ## #68127 — Giuseppe Ronca — 2013-07-15T23:16:15+00:00 URL: https://externals.io/message/68115#68127 · In reply to: #68126 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. --- ## #68128 — Sebastian Krebs — 2013-07-16T11:06:40+00:00 URL: https://externals.io/message/68115#68128 · In reply to: #68126 2013/7/16 Giuseppe Ronca > I've studied Composer and as i thought ..it's a "component installer" > (implementing an autoload system) .. nothing else ( i can have similar > result using git submodules ) > > anyway , *you can have a class collision using or not using composer ( it > doesn't solve it, but just advise you that you can't install that package > )* > I fear having multiple implementations of the same class in the same process will result in something worse than a simple class name collision. Again: It is up to the plugin-/addon-maintainer to keep their products up-to-date and compatible. > > for example, if i require those packages ( that require respectively > monolog 1.3 and monolog 1.2 ) : > > { > "require": { > "dbarbar/campfire-monolog-handler": "dev-master", > "swestcott/monolog-extension": "dev-master" > } > } > > *composer will shows it:* > > - Can only install one of: monolog/monolog[1.3.0, 1.2.0]. > - Can only install one of: monolog/monolog[1.3.0, 1.2.1]. > - *Conclusion: don't install monolog/monolog 1.3.1 * > > so , since both of packages need same library ( but with different version > ) you can't install them. > It's the same limitation that you can find in CMS and external extensions > ...and it's a language issue ofc. > > > 2013/7/15 Marco Pivetta > > > […] > php > > […] > external > > […] > -- github.com/KingCrunch --- ## #68129 — Sebastian Krebs — 2013-07-16T11:11:23+00:00 URL: https://externals.io/message/68115#68129 · In reply to: #68127 2013/7/16 Giuseppe Ronca > You can have multiple objects from the same type in different > > […] > > > No i'm not saying it. > > OK, what then? You have A and B, that both rely on X, but in version 1 and 2. Both A and B are used at the same time. How can now be possible, that X is _not_ instanciated in the same process with different implementations? > > > > […] > > > 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 . > > It will lead to new problems... Lets say you have a third component C, that works both X in both version 1 and 2. So now I say "new X()". What should happen? If 1 is instanciated, it is compatible to A, but if 2 is instanciated it is compatible with B. I cannot simply pass that object to A and/or B. > > > > > […] > > > > 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. > > But I am talking about compatibility in general (or backward compatibility in special). :) -- github.com/KingCrunch --- ## #68130 — Giuseppe Ronca — 2013-07-16T22:29:17+00:00 URL: https://externals.io/message/68115#68130 · In reply to: #68127 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 > You can have multiple objects from the same type in different > > […] > > > No i'm not saying it. > > > > > […] > > > 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 . > > > > > […] > > > > 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. --- ## #72594 — Giuseppe Ronca — 2014-02-14T12:53:37+00:00 URL: https://externals.io/message/68115#72594 · In reply to: #68130 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 : > 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 > > > […] --- ## #72596 — Kevin Ingwersen — 2014-02-14T13:09:26+00:00 URL: https://externals.io/message/68115#72596 · In reply to: #72594 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 : > > > […] --- ## #72710 — Ferenc Kovacs — 2014-02-20T15:48:50+00:00 URL: https://externals.io/message/68115#72710 · In reply to: #72596 On Fri, Feb 14, 2014 at 2:09 PM, Kevin Ingwersen wrote: > 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: > > hi, we prefer bottom (or inline posting with proper truncation of the quoted messages) posting on the php.net mailing lists, please try to follow our mailing list rules when sending a mailt to the list: https://github.com/php/php-src/blob/master/README.MAILINGLIST_RULES if require would be a function, one could use tricks provided by the runkit extension: http://www.php.net/manual/en/function.runkit-function-rename.php but require and variations aren't functions, but language constructs, which means that introducing redirection would be a bit more tricky, plus we also have to consider, that any additional logic to those keywords would slow down the execution for every user. -- Ferenc Kovács @Tyr43l - http://tyrael.hu