---------- Forwarded message ----------
From: Giuseppe Ronca <giuseppe.ron...@gmail.com>
Date: 2013/7/15
Subject: Re: [PHP-DEV] PHP proposal on modular systems
To: Johannes Schlüter <johan...@schlueters.de>


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 <johan...@schlueters.de>

> On Sun, 2013-07-14 at 12:39 +0200, Sebastian Krebs wrote:
> >
> > 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
>
>

Reply via email to