I like this idea, but I think it should be visible by default, and hidden
by using a special namespace import like "use NOLEGACY" or something.
On Jul 19, 2012 3:21 PM, "Michael Morris" <dmgx.mich...@gmail.com> wrote:
> I want to clarify what I mean when I state that the existing API
> should move to a legacy namespace.
>
> First, the only reason to do this is if you want to change the
> behavior of functions to make them consistent. For example, Is it
> haystack, needle or needle, haystack? Second, how namespaces resolve
> may need changing to make this work.
>
> Suppose we have a legacy namespace. That namespace should itself be
> further cordoned so that targeted pieces of it can be brought in if
> desired. For example
>
> \PHP\LEGACY\ARRAY
> \PHP\LEGACY\STRING
>
> If I want to import all functions of a namespace tree into root I would do
>
> use \PHP\LEGACY\ALL;
>
> An ini setting would exist to allow this statement to effectively be
> executed before anything else. That setting could also be in
> .htaccess. By default the setting will be 'on'. So, out of the box,
> old code will work.
>
> What of function name collisions with the new API? Well, one solution
> is that When a function's name collides with one already in the
> namespace the one already present would be unlinked and a notice
> thrown. The other way is to try to design the new API around the old.
> This is where boxing can come into it's own. For example.
>
> $a = array('blue','black','gold');
>
> $a->sort();
>
> // Old code will NOT do this because it isn't possible, so the sort
> function called here would be the new one at this absolute name
>
> \PHP\ARRAY\sort( $array );
>
> By using boxing (which has its own RFC and discussion) we can make the
> new API be able to tolerate the old because of its more heavy use of
> the chaining syntax. There will be collisions - PDO in the new
> interface should return $this on many of its functions to allow for
> chaining, but this is why the user should be able to bring in the
> legacy namespace piecemeal.
>
> Does the legacy namespace go away? Not before PHP 7. PHP 6 has to be
> the version that they live together to allow for transition. PHP 7
> probably should have the legacy API but have it be turned off by
> default.
>
> I'll close this letter by stating the one thing I *DON'T* want to see
> - a legacy API that doesn't let all the old code work. Nothing is
> more infuriating than having an emulator not perfectly emulate.
>
> On Thu, Jul 19, 2012 at 8:44 AM, Andrew Faulds <ajf...@googlemail.com>
> wrote:
> > +1
> >
> > There's a reason that web browser APIs have so much cruft (user-agent
> > string, yuck), and there's a reason for ECMAScript 5's "use strict"
> instead
> > of "use legacy". Old code should work without changing it. Otherwise a
> lot
> > of things break which take a lot of time to fix, and even worse, devs can
> > forget about some project (I know I have), and it breaks without warning.
> > On Jul 19, 2012 1:40 PM, "Lester Caine" <les...@lsces.co.uk> wrote:
> >
> >> Daniel Macedo wrote:
> >>
> >>> What I was stating is that: IF you want to keep the old way of doing
> >>> things around instead of removing them, it should be "change
> >>> settings/tag/whatever so it work as the old way" and not "change it so
> >>> it works the new way", that was my only point.
> >>>
> >>
> >> Obviously you don't support a lot of active websites?
> >> One little change in PHP5.3.10 or so wiped out a whole block of mine,
> and
> >> the fix involved a re-writing all the <?= code across many pages. Simply
> >> because the ISP would not switch back on short tag.
> >> I WILL have all these sites moved to machines I can control all the
> >> configurations of but it all takes time. We simply do not have the time
> to
> >> rewrite everything every time someone decides they don't like 'the old
> >> way', but we need the security fixes since every exploit is better
> >> advertised than the new features !!!
> >>
> >> I repeat what I have said many times ... we need a 'long time stable'
> API
> >> that just gets security updates so that long time stable sites can be
> just
> >> left to work ... If you want to rewrite the manual, then start on a new
> >> fork of PHP please.
> >>
> >> --
> >> Lester Caine - G8HFL
> >> -----------------------------
> >> Contact - http://lsces.co.uk/wiki/?page=**contact<
> http://lsces.co.uk/wiki/?page=contact>
> >> L.S.Caine Electronic Services - http://lsces.co.uk
> >> EnquirySolve - http://enquirysolve.com/
> >> Model Engineers Digital Workshop - http://medw.co.uk
> >> Rainbow Digital Media - http://rainbowdigitalmedia.co.**uk<
> http://rainbowdigitalmedia.co.uk>
> >>
> >>
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
