Sorry , i think you're misunderstanding the main concept of this proposal ..

take a look at this post: http://news.php.net/php.internals/68118 it
explains how you could solve this problem using namespace.
You can actually have 2 version of the same library loaded inside same
process . But namespacing libraries ,using version number encoded in
namespace, is not a common technique...and manually namespacing libraries
is often a long job.

It could be solved by precedent language features IMHO i've exposed. And
many people can gain on this.. Composer too.


2013/7/16 Giuseppe Ronca <giuseppe.ron...@gmail.com>

> You can have multiple objects from the same type in different
>> implemenations in the same process?
>>
>
>
> No i'm not saying it.
>
>
>
>> What should happen, when I instanciate an object of "test" in version X
>> and
>> pass it to a function, that expect it as version Y? To be consistent PHP
>> _must_ trigger an error too, if something from the locally included file
>> leaves its scope
>>
>> class foo {
>>      public static function bar () {
>>           local_include "test.php" / / file which includes "test" class;
>>           return new test (); // <-- error here
>>      }
>> }
>> Because else it is not a local scope anymore.
>>
>
>
> the concept as i said is the same of "nesting" a class inside another ( or
> dynamically namespacing a file )
>
>
> if two different components need "Library v1.0" and "Library v2.0" .. they
> will probably have same classes and namespaces ( but the code is not the
> same ). So how could we use both lib at the same time?   Actually php can't
> load classes in a scope way so you can't do it in any way on global scope.
>
> nesting dynamically libraries inside a namespace or a class , we can
> create objects that can be accessed only throught their root
> namespace/class...something like:
>
> new Version1\ExternalLibrary\FooClass();
>
> new Version2\ExternalLibrary\FooClass();
>
> and also Composer will thankyou about it since they can solve
> automatically problems .
>
>
>
>> Backward compatibility (or compatibility in general) between component is
>> something the plugin maintainer should take care of, not the language.
>> Regards,
>> Sebastian
>
>
>
> i'm talking about backward compatibility of php version...not external
> plugins etc...i think that my idea doesn't require any change to php apps
> to adapt their code.
>
>

Reply via email to