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
