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?
sorry about code formatting mistakes..* *namespace {newversion must
be namespace
newversion { of course
2013/7/14 Giuseppe Ronca giuseppe.ronca2@gmail.com
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-libraryOne 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?
2013/7/14 Giuseppe Ronca giuseppe.ronca2@gmail.com
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
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 http://getcomposer.org/ is a quite good solution which
does a great job in handling projects and its dependencies.
johannes
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 http://getcomposer.org/ 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/
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
On Sun, Jul 14, 2013 at 12:13 PM, Giuseppe Ronca
giuseppe.ronca2@gmail.com 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-libraryOne 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