Hello internals!
After reading the discussion for some time and thinking through what has
been written, I came to the conclusion that something like legacy namespace
witch is enabled by default is required. Why? Because some projects are big
and you usually migrate them in chunks. So that way you
On Fri, 13 Jul 2012, Stas Malyshev wrote:
Has the requirement for a truly clean unicode version of PHP
actually gone away?
The requirement hasn't, but nobody is willing to lead the task. And
it's not an easy one. IMHO variable names are by far the least
important part of it - I don't
On Thu, Jul 19, 2012 at 1:39 PM, Lester Caine les...@lsces.co.uk wrote:
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.
Did you really go
Daniel Macedo wrote:
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.
Did you really go through all code manually to change the short tags?
You
Whilst I feel some sympathy for you, I must ask if it is really the PHP
project to blame if your hosts use old PHP versions?
On Jul 20, 2012 12:50 PM, Lester Caine les...@lsces.co.uk wrote:
Daniel Macedo wrote:
One little change in PHP5.3.10 or so wiped out a whole block of mine, and
the fix
Andrew Faulds wrote:
Whilst I feel some sympathy for you, I must ask if it is really the PHP project
to blame if your hosts use old PHP versions?
Personally I'm fixing the problem and moving everything to my own machines, but
my point is not the personal one ... when ISP's do get around to
According to Rasmus' recent talk, a large part of PHP success came from its
focus on web ecosystem, on what hosting ISPs are effectively needing.
http://talks.php.net/show/supepi/6 (but it's better when you hear Rasmus
telling it)
2012/7/20 Andrew Faulds ajf...@googlemail.com
Whilst I feel
which has made migration a bit more painful than it
needed to be.
Andi
-Original Message-
From: Andrew Faulds [mailto:ajf...@googlemail.com]
Sent: Friday, July 20, 2012 5:20 AM
To: Lester Caine
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] 6.0 And Moving Forward
Whilst I feel some
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
+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
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
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
For a new version to be successful from a marketing perspective, there
has to be such a thing as good old code.
Just as there are PHP 4 apps that are basically sound and maintainable
code and require only a few reasonable changes to run well in PHP 5,
that needs to be true for the transition to 5
To avoid BC breaks we should try to avoid major syntax changes. We could
make new applications hide legacy though, something like use new; which
would remove deprecated and legacy functions from the global namespace.
On Jul 18, 2012 12:16 AM, David Muir davidkm...@gmail.com wrote:
Took the words
I'm wondering if we could include method overloading. Will be pretty nice
mixing it with scalar type hinting or scalar values as objects
On Wed, Jul 18, 2012 at 11:27 AM, Andrew Faulds ajf...@googlemail.comwrote:
To avoid BC breaks we should try to avoid major syntax changes. We could
make new
That would be cool, but couldn't you just detect argument types?
On Jul 18, 2012 5:55 PM, Rafael Kassner kass...@gmail.com wrote:
I'm wondering if we could include method overloading. Will be pretty nice
mixing it with scalar type hinting or scalar values as objects
On Wed, Jul 18, 2012 at
It's possible, but we have to write too much code just to identify all
possible overloads. If methods are overloaded by their signature, surely
the PHP code will be more clean.
Well, I'm just wondering if it is possible without start a war, I'm not
sure how expensive it could be.
On Wed, Jul 18,
On Wed, Jul 18, 2012 at 7:27 AM, Andrew Faulds ajf...@googlemail.comwrote:
To avoid BC breaks we should try to avoid major syntax changes.
Again, why should we be worrying so much about BC breaks on a major version
increment? BC breakage is just a fact of life whenever a major version of
Kris, I'd love to break BC a lot and fix things, but it would seriously
slow adoption. Fixing *bugs* has stopped people upgrading, imagine how they
would react to non-bugs being changed.
On Jul 18, 2012 7:21 PM, Kris Craig kris.cr...@gmail.com wrote:
On Wed, Jul 18, 2012 at 7:27 AM, Andrew
On Wed, Jul 18, 2012 at 12:09 PM, Andrew Faulds ajf...@googlemail.comwrote:
Kris, I'd love to break BC a lot and fix things, but it would seriously
slow adoption. Fixing *bugs* has stopped people upgrading, imagine how they
would react to non-bugs being changed.
I agree with your point. I
If there's this big conflict between BC breaks being bad because they
discourage adoption and make old code unusable on the one hand, and
good because they allow many things to be cleaned up and progress to
be made, then why not pursue a three-pronged approach:
1. BC breaks are made wherever it
use a slightly modified version of the open tag, for example ?php6 or
*php, etc. This satisfies several desires: we don't want an extra
line of boilerplate code like 'use PHP 6' to be required in every
source file, we want a PHP 5 file to run without modification, and we
want a PHP 6 file to
Chaos will surely be, if we break PHP5 code. It should work without
modification. ?php6 is fine, ?php isn't.
On Jul 18, 2012 9:34 PM, Daniel Macedo admac...@gmail.com wrote:
use a slightly modified version of the open tag, for example ?php6 or
*php, etc. This satisfies several desires: we
I do like the idea of pseudo-objects with methods as a way to create
much cleaner APIs for strings and arrays, but the legacy APIs need to
stick around.
You don't need to break BC to remove legacy APIs in PHP6.
#1. Introduce the new APIs in 5.x and gradually mark the old ones as
deprecated,
Chaos will surely be, if we break PHP5 code. It should work without
modification. ?php6 is fine, ?php isn't.
On Jul 18, 2012 9:34 PM, Daniel Macedo admac...@gmail.com wrote:
People are forgetting why we have version numbers.
Yes, it's very spectacular to have all the new stuff in a major
...er, php5 isn't fine.
On Jul 18, 2012 9:34 PM, Daniel Macedo admac...@gmail.com wrote:
use a slightly modified version of the open tag, for example ?php6 or
*php, etc. This satisfies several desires: we don't want an extra
line of boilerplate code like 'use PHP 6' to be required in every
Sure, BC breaks for 6.0, but it worries me. I don't want a Python 3 for PHP
6. Or heck, PHP5 for that matter.
On Jul 18, 2012 9:50 PM, Stan Vass sv_for...@fmethod.com wrote:
Chaos will surely be, if we break PHP5 code. It should work without
modification. ?php6 is fine, ?php isn't.
On Jul 18,
People are forgetting why we have version numbers.
Yes, it's very spectacular to have all the new stuff in a major release, but
that's not what major versions are for.
Major versions are for BC breaks. And point releases are for BC-compatible
new features.
Therefore in 5.x releases old and
That would be nice and all, but I'd rather we add methods to arrays.
On Jul 17, 2012 1:26 AM, David Muir davidkm...@gmail.com wrote:
On 14/07/12 01:33, Anthony Ferrara wrote:
Hey all,
I know that 6.0 was originally supposed to be the unicode conversion of
the
engine. However it appears
Hi,
On 07/17/2012 05:40 AM, Nicholas Curtis wrote:
Great Idea, would love to see current standard library in a legacy
namespace and a new standard library implemented as methods of
primitive types.
The idea to separate old and new behaviour has some charm.
$string = Hello, World;
echo
you have to change existing code (if I understand your syntax
correctly)
I think the idea here is to put functions likes floor and round in a legacy
namespace of sorts, so they are not accessible in the global namespace.
Then you have an .ini directive that imports the legacy namespace into
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
I like this idea a lot. I use PHP at work, and run everything on dedicated
servers so I'd definitely prefer to run a pure PHP6 setup. Hosting
providers on the other hand can over PHP5 support via an extension.
+1
On Tue, Jul 17, 2012 at 9:51 AM, Leigh lei...@gmail.com wrote:
Basically, the
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 lei...@gmail.com wrote:
Basically, the current function library is moved to the legacy
namespace. The default setting is import
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
Aren't certain modules included in the PHP core distribution, like the
mysqli extension that you enable using --with-mysqli?
Could we not include the PHP5 namespace as an extension with the PHP
distribution, and have it enabled by default, but provide a
--disable-legacy-namespace option?
Then in
Well, being able to disable the fallback would allow developers to eagerly
discover features that are going to be dropped (and it doesn't need to be a
soft failure).
Marco Pivetta
http://twitter.com/Ocramius
http://marco-pivetta.com
On 17 July 2012 16:14, Brandon Wamboldt
I agree, and it allows developers who don't need/want PHP5 compatibility to
just disable the legacy namespace, reducing cruft and allowing them to
prepare for future versions of PHP.
Developers or hosting providers who need to support PHP5 can just
compile/install PHP with default settings which
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
Hi,
Some of the things I want to see in PHP 6:
New designed Standard Library:
* Clearly defined conventions for organization, naming and error handling.
* Use Namespaces and groups functions by their purpose (net, strings,
arrays,…)
* Promote SPL functionality (spl_autoload_register, Data
I'd really like to see full unicode support as well, scalar values as
objects with methods ($intVar-abs()), and the ability to import all
classes/functions from a namespace.
On Tue, Jul 17, 2012 at 11:37 AM, Leigh lei...@gmail.com wrote:
While I think having a legacy implementation is
The problem, of course, is changing and removing things can break BC. I'd
love to remove list() too, but that would break code relying on it.
On Jul 17, 2012 4:23 PM, Christoph Hochstrasser
christoph.hochstras...@gmail.com wrote:
Hi,
Some of the things I want to see in PHP 6:
New designed
I thought list() was a syntax, not standard lib, feature? Like array() (or
am I thinking of isset()?)
On Jul 17, 2012 4:48 PM, Dan Cryer d...@dancryer.com wrote:
The problem, of course, is changing and removing things can break BC. I'd
love to remove list() too, but that would break code
The problem, of course, is changing and removing things can break BC. I'd
love to remove list() too, but that would break code relying on it.
Isn't that kind of the point of the whole discussion? This is talking about
completely rewriting the standard library for PHP 6, but providing a legacy
You're correct, list() is a language construct. Is it still possible to add
that in via an extension somehow?
On Tue, Jul 17, 2012 at 1:00 PM, Andrew Faulds ajf...@googlemail.comwrote:
I thought list() was a syntax, not standard lib, feature? Like array() (or
am I thinking of isset()?)
On Jul
On Tue, Jul 17, 2012 at 8:48 AM, Dan Cryer d...@dancryer.com wrote:
The problem, of course, is changing and removing things can break BC. I'd
love to remove list() too, but that would break code relying on it.
Isn't that kind of the point of the whole discussion? This is talking about
On Tue, Jul 17, 2012 at 3:43 PM, Kris Craig kris.cr...@gmail.com wrote:
On Tue, Jul 17, 2012 at 8:48 AM, Dan Cryer d...@dancryer.com wrote:
The problem, of course, is changing and removing things can break BC.
I'd
love to remove list() too, but that would break code relying on it.
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),
When Adobe moved from Actionscript 2 to Actionscript 3 they placed all
existing functions into a legacy namespace. Similarly, I believe that
may be PHP's best shot for smoothing out the API.
Basically, the current function library is moved to the legacy
namespace. The default setting is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
1. Change the error handling system from the current E_* system to
typed exceptions for everything but advisory errors (E_STRICT,
E_NOTICE, E_DEPRECATED). Why? Because the current error system
encourages ignoring or not checking what the error
Yeah, we could do something like Java: primitive typed and OOP wrapped
types.
On Jul 16, 2012 10:25 AM, Ralf Lang l...@b1-systems.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
1. Change the error handling system from the current E_* system to
typed exceptions for everything but
On 14/07/12 01:33, Anthony Ferrara wrote:
Hey all,
I know that 6.0 was originally supposed to be the unicode conversion of the
engine. However it appears that all progress on that has stopped for quite
some time.
So, I was curious if we could start a conversation around what 6.0 would
look
Great Idea, would love to see current standard library in a legacy
namespace and a new standard library implemented as methods of
primitive types.
$string = Hello, World;
echo $strong-toUpper(); // HELLO, WORLD
$int = 3;
echo $int-round(2); // 3.0
While still preserving
When Adobe moved from Actionscript 2 to Actionscript 3 they placed all
existing functions into a legacy namespace. Similarly, I believe that
may be PHP's best shot for smoothing out the API.
Basically, the current function library is moved to the legacy
namespace. The default setting is import
I don't understand this 100% but it sounds awesome. +1
On Sun, Jul 15, 2012 at 12:14 PM, Michael Morris dmgx.mich...@gmail.comwrote:
When Adobe moved from Actionscript 2 to Actionscript 3 they placed all
existing functions into a legacy namespace. Similarly, I believe that
may be PHP's best
I'd like to address the most obvious issues I see with moving on to PHP 6.
First, there has already been a lot of discussion on PHP 6 since as
early as 2007, if I recall correctly. Albeit, a lot of this has died
down over the years, but there are probably still a lot of books and
people out there
hi,
On Sat, Jul 14, 2012 at 8:14 AM, Sherif Ramadan theanomaly...@gmail.com wrote:
I'd like to address the most obvious issues I see with moving on to PHP 6.
First, there has already been a lot of discussion on PHP 6 since as
early as 2007, if I recall correctly. Albeit, a lot of this has
Sherif Ramadan wrote:
I propose choosing a different version naming for the next branch.
Perhaps we can skip 6 since it got nowhere and move right to 7. I'm
sure that's superficial right now, but will be important for the sake
of not confusing anyone that may have read or heard about what PHP 6
+1 :)
-Original Message-
From: Kris Craig [mailto:kris.cr...@gmail.com]
Sent: Friday, July 13, 2012 11:47 AM
To: Anthony Ferrara
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] 6.0 And Moving Forward
4. Rewrite the entire parser completely. I keep hearing about how bad
On 2012-07-14 04:12, jpauli wrote:
On Fri, Jul 13, 2012 at 5:33 PM, Anthony Ferrara ircmax...@gmail.com wrote:
4. Rewrite the entire parser completely. I keep hearing about how bad PHP's
parser is, and how it's growing out of control. Perhaps this is a good time
to rewrite it (perhaps changing
Anthony Ferrara wrote:
1. Change the error handling system from the current E_* system to typed
exceptions for everything but advisory errors (E_STRICT, E_NOTICE,
E_DEPRECATED). Why? Because the current error system encourages ignoring or
not checking what the error was, and it makes defensive
On Fri, Jul 13, 2012 at 5:33 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Hey all,
I know that 6.0 was originally supposed to be the unicode conversion of the
engine. However it appears that all progress on that has stopped for quite
some time.
So, I was curious if we could start a
4. Rewrite the entire parser completely. I keep hearing about how bad PHP's
parser is, and how it's growing out of control. Perhaps this is a good time
to rewrite it (perhaps changing semantics slightly) to be better adapted
towards future changes...
I'm bored so I'm gonna poke the
Anthony Ferrara wrote:
I know that 6.0 was originally supposed to be the unicode conversion of the
engine. However it appears that all progress on that has stopped for quite
some time.
Has the requirement for a truly clean unicode version of PHP actually gone away?
Yes on the whole the
Hi!
Has the requirement for a truly clean unicode version of PHP actually gone
away?
The requirement hasn't, but nobody is willing to lead the task. And it's
not an easy one. IMHO variable names are by far the least important part
of it - I don't know of any code that can't be done using
Hey all,
I know that 6.0 was originally supposed to be the unicode conversion of the
engine. However it appears that all progress on that has stopped for quite
some time.
So, I was curious if we could start a conversation around what 6.0 would
look like if we didn't go the unicode route. What
66 matches
Mail list logo
