Took the words from my mouth. Removing legacy support is a terrible idea for PHP6. It makes it impossible to write forwards compatible code that currently runs in PHP5. Even having it optional is a bad idea IMO since it will fragment PHP hosting. Some will be able to run PHP6 only (no legacy), some will be able to run PHP5+ but will still be marketed as PHP6. Makes it that much harder to know if your code will run on a client's server.
David
On 18/07/12 00:04, Anthony Ferrara wrote:
I dislike this idea from the ground up.
While I think having a legacy implementation is definitely worth while, it
needs to be in core. So PHP6 would introduce the new syntax, and include
the legacy functionality in as close to 100% backwards compatible way as
possible. From there, we'd only remove the legacy functionality from core
in 7 (which could be 4 or 5 years out).
We don't want to be in the same situation with 6 that python was in with 3,
and perl was in 5. We want to encourage adoption. Having a PECL extension
needed for adoption is not going to fly too well. But if we can add the new
functionality and give people an easy migration path, adoption will be
easier. It still may take years, but it will at least be fairly smooth as
the majority of existing code will still work. Of course some BC breaks may
be necessary (a-la what happened with PHP5), but they should be fairly
localized and pretty easy to handle... And they should be justified
(breaking BC for the sake of it, as with these legacy functions, would be a
mistake)...
My $0.02 at least.
Anthony
On Tue, Jul 17, 2012 at 9:41 AM, Andrew Faulds <
[email protected]>wrote:
This is an excellent idea. Full BC yet without legacy cruft. Old code runs
on legacy support extensions, new code doesn't need it.
On Jul 17, 2012 1:51 PM, "Leigh" <
[email protected]> wrote:
Basically, the current function library is moved to the legacy
namespace. The default setting is import the functions of the legacy
namespace into the root namespace for BC. But with that setting
turned off all the existing functions go away to be replaced with a
designed API, instead of a grown one, correcting the mistakes that
have accumulated over the years.
Is there any reason why this cannot / should not be implemented as a
PHP 5 compatibility extension?
I think those who never want to use it (PHP 6 purists) shouldn't have
to have their binaries bloated by legacy code. It would also mean that
the legacy implementation can be developed away from the new core, and
not have any (negative) influence on it.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
http://www.php.net/unsub.php