Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68116
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+wXisVVDaQYL+drdonNhxD=+=CWpES5K9UPsx40EvrXAAG3Yw@mail.gmail.com>
References: <CA+wXisVVDaQYL+drdonNhxD=+=CWpES5K9UPsx40EvrXAAG3Yw@mail.gmail.com>
Date: Sun, 14 Jul 2013 12:39:18 +0200
Message-ID: <CALtuQzBh-9gWv843tRNie6=C_w4eFcxyTB9692XFz+XrVT352g@mail.gmail.com>
To: Giuseppe Ronca <giuseppe.ronca2@gmail.com>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0141aa2a8e3ca604e1765d3e
Subject: Re: [PHP-DEV] PHP proposal on modular systems
From: krebs.seb@gmail.com (Sebastian Krebs)

--089e0141aa2a8e3ca604e1765d3e
Content-Type: text/plain; charset=ISO-8859-1

2013/7/14 Giuseppe Ronca <giuseppe.ronca2@gmail.com>

> Php is now used by many CMS, many of which use a modular system with a wide
> range of add-ons developed by third parties. This can cause various
> conflicts, such as when two or more external components using the same
> library (i.g. with a different version) in this case the classes /
> namespace will be in collision. This can become unmanageable by the
> webmaster because they are not always able to change third parties code and
> there aren't other "clean" methods to solve this kind of problem ( complex
> and dirty eval methods excluded ).
>
> here you are a thread related to this issue:
>
> http://stackoverflow.com/questions/17628475/php-include-different-version-of-same-library
>
> *One possible solution* would be to extend the scoping for the inclusions
> of files using something like:* local_include_**
>
> in this way you can also create a sort of "nesting" system for classes
> making possible a syntax like this:
>
> class foo {
>      public static function bar () {
>           local_include "test.php" / / file which includes "test" class;
>           return new test ();
>      }
> }
>
> echo get_class (foo :: bar ()) / / output: "test"
>
> new test () / / raise an error instead
>
>
> *Also this could work:*
>
> namespace {oldversion
>     local_include / lib/api-1.0/library.php;
> }
> namespace {newversion
>     local_include / lib/api-2.0/library.php;
> }
>
> $ oldlibary = new oldversion \ Library ();
> $ newlibrary = new newversion \ Library ();
>
> It shouldn't have backward compatibility issues since it's a new
> implementation and you shouldn't change anything else.
> What do you think about that?
>

You can have multiple objects from the same type in different
implemenations in the same process?

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.

Backward compatibility (or compatibility in general) between component is
something the plugin maintainer should take care of, not the language.

Regards,
Sebastian




-- 
github.com/KingCrunch

--089e0141aa2a8e3ca604e1765d3e--