2013/7/16 Giuseppe Ronca <giuseppe.ron...@gmail.com>
> 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 <ocram...@gmail.com>
>
> >
> > On 15 July 2013 16:51, Giuseppe Ronca <giuseppe.ron...@gmail.com> wrote:
> >
> >> 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/
> >
>
--
github.com/KingCrunch
