Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68120
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+wXisVVDaQYL+drdonNhxD=+=CWpES5K9UPsx40EvrXAAG3Yw@mail.gmail.com>
References: <CA+wXisVVDaQYL+drdonNhxD=+=CWpES5K9UPsx40EvrXAAG3Yw@mail.gmail.com>
Date: Mon, 15 Jul 2013 15:19:11 +0200
Message-ID: <CAA9esySAgb9ut5jntvqrxxT5WMwxo77KarowparwJxB4-8AYkA@mail.gmail.com>
To: Giuseppe Ronca <giuseppe.ronca2@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] PHP proposal on modular systems
From: florinpatan@gmail.com (Florin Patan)

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-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