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 <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/
>
