Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68128
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+wXisWnBwcHxSHha3Vk9KcPXbzL8BCWhDEpHrr+EMdLPF2e4Q@mail.gmail.com>
References: <CA+wXisVVDaQYL+drdonNhxD=+=CWpES5K9UPsx40EvrXAAG3Yw@mail.gmail.com>
 <CALtuQzBh-9gWv843tRNie6=C_w4eFcxyTB9692XFz+XrVT352g@mail.gmail.com>
 <1373879683.17031.4.camel@guybrush> <CA+wXisVXVxquXm+MZrOwoC_+PqWptdzhxv-VtRQoyn8Hwuxsug@mail.gmail.com>
 <CA+wXisUWGf3jA8ZWWkSHYdjUq46Ez1O7-Fk9VXG5Nj-mw-2euQ@mail.gmail.com>
 <CADyq6sJT5bjW0PbETLCaiLdqiX+jzSRAx4L3_ZoeT2FPOVVXoQ@mail.gmail.com> <CA+wXisWnBwcHxSHha3Vk9KcPXbzL8BCWhDEpHrr+EMdLPF2e4Q@mail.gmail.com>
Date: Tue, 16 Jul 2013 13:06:40 +0200
Message-ID: <CALtuQzB+jhojsR8FcUyQV2aUpt1R+aY-VO4p4o6Yg+f=3b4dNg@mail.gmail.com>
To: Giuseppe Ronca <giuseppe.ronca2@gmail.com>
Cc: Marco Pivetta <ocramius@gmail.com>, PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d044481c7124df404e19efb2d
Subject: Re: [PHP-DEV] PHP proposal on modular systems
From: krebs.seb@gmail.com (Sebastian Krebs)

--f46d044481c7124df404e19efb2d
Content-Type: text/plain; charset=ISO-8859-1

2013/7/16 Giuseppe Ronca <giuseppe.ronca2@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 <ocramius@gmail.com>
>
> >
> > On 15 July 2013 16:51, Giuseppe Ronca <giuseppe.ronca2@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

--f46d044481c7124df404e19efb2d--