that front 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 Mov
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
> Whilst I feel some sympathy for you, I
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 upd
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" wrote:
> Daniel Macedo wrote:
>
>> >One little change in PHP5.3.10 or so wiped out a whole block of mine, and
>>> >the fix involved
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 because the ISP would not switch back on short tag.
Did you really go through all code manually to change the short tags?
You should be smarter than that:
https:
On Thu, Jul 19, 2012 at 1:39 PM, Lester Caine 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 because the ISP would not switch back on short tag.
Did you really go through all code manually to change the short tags?
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
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
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" wrote:
> I want to clarify what I mean when I state that the existing API
> should move to a legacy namespace.
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
+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
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 suppor
> 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 ol
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" wrote:
> Chaos will surely be, if we break PHP5 code. It should work without
>> modification. > On Jul 18, 2012 9:34 PM, "Daniel Macedo" wrote:
>>
>
...er, wrote:
> > use a slightly modified version of the open tag, for example > <*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
> >
Chaos will surely be, if we break PHP5 code. It should work without
modification. wrote:
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. An
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, b
Chaos will surely be, if we break PHP5 code. It should work without
modification. wrote:
> > use a slightly modified version of the open tag, for example > <*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
> >
> use a slightly modified version of the open tag, for example <*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 be ab
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 mak
On Wed, Jul 18, 2012 at 12:09 PM, Andrew Faulds wrote:
> 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 guess my thinking
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" wrote:
>
>
> On Wed, Jul 18, 2012 at 7:27 AM, Andrew Faulds wrote:
>
>>
On Wed, Jul 18, 2012 at 7:27 AM, Andrew Faulds wrote:
> 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
anything comes out. Beca
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,
That would be cool, but couldn't you just detect argument types?
On Jul 18, 2012 5:55 PM, "Rafael Kassner" 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 11:27 AM, Andr
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 wrote:
> To avoid BC breaks we should try to avoid major syntax changes. We could
> make new applications "hide"
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" wrote:
> Took the words from my mouth
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
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),
On Tue, Jul 17, 2012 at 3:43 PM, Kris Craig wrote:
>
>
> On Tue, Jul 17, 2012 at 8:48 AM, Dan Cryer 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
On Tue, Jul 17, 2012 at 8:48 AM, Dan Cryer 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
> completel
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 wrote:
> 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,
>
> 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 lega
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" 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.
>
>
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 de
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 wrote:
> > While I think having a legacy implementation is definitely worth while
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", Da
> 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 c
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 w
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 wrote:
> Aren't ce
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
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 remov
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" wrote:
> > Basically, the current function library is moved to the legacy
> > namespace. The default setting is import the functions
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 wrote:
> > Basically, the current function
> 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 o
>
> 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 in
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";
> ec
That would be nice and all, but I'd rather we add methods to arrays.
On Jul 17, 2012 1:26 AM, "David Muir" 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 that all p
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 $legacy.strTopUpper($
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 like
Yeah, we could do something like Java: primitive typed and OOP wrapped
types.
On Jul 16, 2012 10:25 AM, "Ralf Lang" wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> > 1. Change the error handling system from the current E_* system to
> > typed exceptions for everything but advisory er
-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
> 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
I don't understand this 100% but it sounds awesome. +1
On Sun, Jul 15, 2012 at 12:14 PM, Michael Morris wrote:
> 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 o
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 t
On 2012-07-14 04:12, jpauli wrote:
On Fri, Jul 13, 2012 at 5:33 PM, Anthony Ferrara 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 semantics slightly)
+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 e
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
w
hi,
On Sat, Jul 14, 2012 at 8:14 AM, Sherif Ramadan 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 died
> down over the ye
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!
> 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 ASC
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 existin
>
>
> 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
On Fri, Jul 13, 2012 at 5:33 PM, 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
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 defens
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 wou
66 matches
Mail list logo
