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 would be the major
changes that we'd base it on.
Here are a few of the ideas that have been floating around in my head.
-
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 programming quite
difficult. This is arguable and preference for sure, but it's a major
change that could have large benefits. -
Make namespaces first-class meta-objects. That way, you could have
namespace private and protected classes, functions, variables, etc. This
would allow for better scoping of modules... -
Make all zval types pseudo-objects. Basically enabling something akin to
auto-boxing allowing a significant amount of the standard library to be
eventually deprecated in favor of acting on methods (not initially, but
opens the door). -
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 not saying all of them are solid. I'm not saying any of them are solid.
But hopefully this can spark a discussion around it...
Thoughts?
Anthony
Anthony Ferrara wrote:
- 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 programming quite
difficult. This is arguable and preference for sure, but it's a major
change that could have large benefits.
+1. It's strange to me that PHP doesn't use exceptions in the areas
where they apply. For example, catchable fatal errors could almost
always be represented as an exception for better handling (IMHO).
- Make all zval types pseudo-objects. Basically enabling something akin to
auto-boxing allowing a significant amount of the standard library to be
eventually deprecated in favor of acting on methods (not initially, but
opens the door).
+1. I'd love to be able to extend primitive types. If that's possible,
methods on primitives could be implemented entirely in userland.
I'd also like to see more Unicode (by which I mean UTF-8). I'd like to
see the string methods split into byte-level and character-level where
needed, with character-level functions based on mbstring.
Ryan McCue
<http://ryanmccue.info/
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 would be the major
changes that we'd base it on.
Will it be named 6.0 ? That's the first question.
We should, IMO, open a huge wiki page to aggregate our ideas. No
voting stuff at all for the moment, just throw ideas like you did in
this mail.
The RFC could then be split later in severals little ones if needed.
Debate like "+1"s should appear on the mailing list though. "+1"s are
just first advices, needing deeper investigation; ML is then a good
place for that.
Here are a few of the ideas that have been floating around in my head.
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 programming quite
difficult. This is arguable and preference for sure, but it's a major
change that could have large benefits.Make namespaces first-class meta-objects. That way, you could have
namespace private and protected classes, functions, variables, etc. This
would allow for better scoping of modules...Make all zval types pseudo-objects. Basically enabling something akin to
auto-boxing allowing a significant amount of the standard library to be
eventually deprecated in favor of acting on methods (not initially, but
opens the door).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...
We have an RFC and a patch playing with lemon parser. Actually, just a
conversion, reentrant.
Refer to Pierrick or Felipe about it :-)
I'm not saying all of them are solid. I'm not saying any of them are solid.
But hopefully this can spark a discussion around it...
I would have added merging the SPL code to ZendEngine, somehow.
Thanks !
Julien
- 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 hornet's nest: Anyone up for converting
the whole damn thing to C++?
I welcome your hatred. Muaa ha ha ha! ;)
--Kris
+1 :)
-----Original Message-----
From: Kris Craig [mailto:kris.craig@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
- 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 hornet's nest: Anyone up for converting the whole damn thing to C++?
I welcome your hatred. Muaa ha ha ha! ;)
--Kris
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 existing code can handle unicode content without breaking
it, and in a few places unicode names can be used, but the ability to write
scripts using unicode so that local translations of variable names can be used
still has a place in this multilingual world. The discussion about tolower and
the problems created by sections of php not being case sensitive are probably
the major stumbling block to a unicode version of PHP? Personally I am limited
to UK English, so I can live with the restrictions, but I CAN see it being
something of a blocker in the rest of the world where English is simply another
hurdle, and I have always considered using different case versions of the same
function as simply wrong. Lets just drop case insensitivity.
So rather than adding more and more hurdles to maintaining existing code, can
the initial discussion be 'Just how far should support for unicode go?'
- 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 programming quite
difficult. This is arguable and preference for sure, but it's a major
change that could have large benefits.
Having already spent several weeks working on re-writing perfectly clean PHP5.2
code to remove all of the E_STRICT, E_NOTICE and E_DEPRECATED warnings my own
view is that the bulk of those changes have added nothing to any of the
applications !!! The exercise had to be done simply to get around all the
problems created by PHP5.3/4 installations that had not considerer how older
code should be handled ... and simply broke it ... and most of the ISP's of the
sites I've helped get working again have only just 'upgraded' to PHP5.3 ...
--
Lester Caine - G8HFL
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
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 ASCII only :)
function as simply wrong. Lets just drop case insensitivity.
That pretty much precludes smooth upgrade to 6.0 for existing
applications. I don't see much value in it. And again, case
insensitivity wasn't a problem for Unicode engine (we can't use tolower
there of course but we can use case folding).
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
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 with misconceptions about PHP 6 and this could lead
to further confusion. I believe it's important to try and make any
future transitions into PHP easier.
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
was once planned to be.
Second, I agree with moving towards exceptions and away from E_* error
levels. The fact that individual PHP functions have different ways of
dealing with errors, and that PHP error constants tend to change over
time, makes a lot of the error handling stuff pretty rigid and
non-obvious.
I'm not sure about making scalars objects and all the unicode stuff,
but I think for the most part PHP needs tweaks to the parser. I also
hear a lot of copmlaints about that. I'd favor a complete rewrite of
the parser.
hi,
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 with misconceptions about PHP 6 and this could lead
to further confusion. I believe it's important to try and make any
future transitions into PHP easier.
PHP 6 never existed, we never did any release, I see no appealing but
pointless marketing reason to skip this version. I see however many
very good reasons not to skip it.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
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
was once planned to be.
Which is perhaps why we had 5.3 with some major structural changes when that
would have been better with a major number advance ... The confusion at that
time with PHP6 'roadmap' prevented leaving PHP5.2 with some better longer term
support.
But I agree with Pierre that skipping 6 is a little pointless just because
people jumped on a bandwagon that had not even been put into Alpha and produced
vapourware books.
The problem currently is producing a roadmap that we can all agree on and are
happy to work towards. I see some of the re-factoring as a lot more practical
than some of the facilities that are being forced on us by the likes of E_STRICT
compliance. Many of my existing sites will never be E_STRICT compliant, it's not
worth the time, so I need to maintain a version of PHP that supports those sites
securely! And PHP5.2 is still the safest base for those sites but is no longer
'secure' ... how many hundreds of thousands of sites currently live need all of
the PHP5.3+ facilities switched off?
--
Lester Caine - G8HFL
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
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 ASCII only :)
Variables name can already be in UTF-8 just fine. My favourite is adding
a non breaking space in a function name, like in the attached file ;-)
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- 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 programming quite difficult. This is arguable and
preference for sure, but it's a major change that could have large
benefits.
I like that one. Proposed something like this a while ago but back
then it did not fit into a minor release's scope and limitations.
Thoughts?
Provide a stock "Number" and "String" object if primitives themselves
cannot be turned into objects for bc reasons.
Ralf Lang
Linux Consultant / Developer
B1 Systems GmbH
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlAD3fQACgkQCs1dsHJ/X7BLqwCg4/9mj2tgiBQtV6JZteJ0Fqat
bhwAoPMQy7M8CA2Ni4unFcRMDeUFiImg
=xRS8
-----END PGP SIGNATURE
Yeah, we could do something like Java: primitive typed and OOP wrapped
types.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- 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 programming quite difficult. This is arguable and
preference for sure, but it's a major change that could have large
benefits.I like that one. Proposed something like this a while ago but back
then it did not fit into a minor release's scope and limitations.Thoughts?
Provide a stock "Number" and "String" object if primitives themselves
cannot be turned into objects for bc reasons.
Ralf Lang
Linux Consultant / Developer
B1 Systems GmbH
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/iEYEARECAAYFAlAD3fQACgkQCs1dsHJ/X7BLqwCg4/9mj2tgiBQtV6JZteJ0Fqat
bhwAoPMQy7M8CA2Ni4unFcRMDeUFiImg
=xRS8
-----END PGP SIGNATURE
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($string) and $legacy.round($int)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- 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 programming quite difficult. This is arguable and
preference for sure, but it's a major change that could have large
benefits.I like that one. Proposed something like this a while ago but back
then it did not fit into a minor release's scope and limitations.Thoughts?
Provide a stock "Number" and "String" object if primitives themselves
cannot be turned into objects for bc reasons.
Ralf Lang
Linux Consultant / Developer
B1 Systems GmbH
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/iEYEARECAAYFAlAD3fQACgkQCs1dsHJ/X7BLqwCg4/9mj2tgiBQtV6JZteJ0Fqat
bhwAoPMQy7M8CA2Ni4unFcRMDeUFiImg
=xRS8
-----END PGP SIGNATURE
Hi,
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 $strong->toUpper(); // HELLO, WORLD$int = 3;
echo $int->round(2); // 3.0While still preserving $legacy.strTopUpper($string) and
$legacy.round($int)
I wouldn't do that because it implies two things:
-
you have to change existing code (if I understand your syntax
correctly) -
you could mix old and new style in one file
Somebody proposed (in some other thread some weeks ago) to introduce
some code versioning. IIRC he proposed the "<?php6" opening tag instead
of "<?php". (I'd prefer something like "<?php+" - but that's just a
naming thing. And of course: You could still mix different styles in one
file - but not in one php block. And that's easier to handle by coding
conventions in the team.)
Versioning could be a chance to evolve the language and not to mess with
existing code. BUT: I don't know if that's doable internally. And it's
probably a lot of work...
Regards
Thomas
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 the
global namespace. Disable the .ini directive for 100% PHP6 mode, leave it
in for legacy support.
If it's enabled, you could mix round( $int ) and $int->round() in the same
file.
That's my understanding at least.
On Tue, Jul 17, 2012 at 6:07 AM, Thomas Nunninger thomas@nunninger.infowrote:
Hi,
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 $strong->toUpper(); // HELLO, WORLD$int = 3;
echo $int->round(2); // 3.0While still preserving $legacy.strTopUpper($string) and
$legacy.round($int)I wouldn't do that because it implies two things:
you have to change existing code (if I understand your syntax
correctly)you could mix old and new style in one file
Somebody proposed (in some other thread some weeks ago) to introduce some
code versioning. IIRC he proposed the "<?php6" opening tag instead of
"<?php". (I'd prefer something like "<?php+" - but that's just a naming
thing. And of course: You could still mix different styles in one file -
but not in one php block. And that's easier to handle by coding conventions
in the team.)Versioning could be a chance to evolve the language and not to mess with
existing code. BUT: I don't know if that's doable internally. And it's
probably a lot of work...Regards
Thomas--
--
Brandon Wamboldt
Programmer / Web Developer
StackOverflow Careers
Profilehttp://careers.stackoverflow.com/brandonwamboldt- GitHub
Profile https://github.com/brandonwamboldt -
LinkedInhttps://github.com/brandonwamboldt -
My Blog <http://brandonwamboldt.ca/
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 would be the major
changes that we'd base it on.Here are a few of the ideas that have been floating around in my head.
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 programming quite
difficult. This is arguable and preference for sure, but it's a major
change that could have large benefits.Make namespaces first-class meta-objects. That way, you could have
namespace private and protected classes, functions, variables, etc. This
would allow for better scoping of modules...Make all zval types pseudo-objects. Basically enabling something akin to
auto-boxing allowing a significant amount of the standard library to be
eventually deprecated in favor of acting on methods (not initially, but
opens the door).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 not saying all of them are solid. I'm not saying any of them are solid.
But hopefully this can spark a discussion around it...Thoughts?
Anthony
I'd really like to see the following being possible:
$array = array('foo' => 'bar');
$object = (object) $array;
echo $array['foo']; //bar
echo $array->foo; //bar
echo $object['foo']; //bar
echo $object->foo; //bar
Is there a technical reason for the difference that currently exists?
Cheers,
David
That would be nice and all, but I'd rather we add methods to arrays.
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 would be the major
changes that we'd base it on.Here are a few of the ideas that have been floating around in my head.
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 programming quite
difficult. This is arguable and preference for sure, but it's a major
change that could have large benefits.Make namespaces first-class meta-objects. That way, you could have
namespace private and protected classes, functions, variables, etc. This
would allow for better scoping of modules...Make all zval types pseudo-objects. Basically enabling something akin
to
auto-boxing allowing a significant amount of the standard library to be
eventually deprecated in favor of acting on methods (not initially, but
opens the door).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 not saying all of them are solid. I'm not saying any of them are
solid.
But hopefully this can spark a discussion around it...Thoughts?
Anthony
I'd really like to see the following being possible:
$array = array('foo' => 'bar');
$object = (object) $array;echo $array['foo']; //bar
echo $array->foo; //barecho $object['foo']; //bar
echo $object->foo; //barIs there a technical reason for the difference that currently exists?
Cheers,
David
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 structures) to proper
Core APIs by dropping the "SPL" prefix. - Converts all resource based APIs (file, stream,…) to Object Oriented APIs
- Maybe find a way to share the standard library between multiple implementations
of PHP (HipHop, Quercus, Phalanger).
A better parser which is more maintainable and makes it easier to implement
language features every modern programming language has.
- Slicing operators for Arrays (and Strings?)
- Splice Operator: splits an array into arguments for a function call.
Then we can finally removecall_user_func_array(). - Optional Semicolons? I recently started doing some programming in Go and I
really like this.
Clean up the language:
- Remove the old array() declaration syntax.
- Replace some keywords with syntax constructs. For example remove list() and
use multi assignment syntax like $var1, $var2 = foo(); or remove the array()
syntax. Makes names like "List" and "Array" usable as Userspace class names
again.
Remove features which were made obsolete by the SPL:
- __autoload() — was made obsolete by
spl_autoload_register() -
dir()— DirectoryIterator, probably makedir()just return a DirectoryIterator. - probably more.
Make some runtime features more consistent:
- Autoloading for all kind of missing constants (function names, namespace constants)
- Function importing just like Class importing
- Language Specification which makes it easier to maintain competing implementations.
There's probably a lot more we could do, but these are some things from right the
top of my head.
--
Christoph Hochstrasser
http://twitter.com/hochchristoph | http://christophh.net | https://github.com/CHH
Am Freitag, 13. Juli 2012 um 17:33 schrieb Anthony Ferrara:
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 would be the major
changes that we'd base it on.Here are a few of the ideas that have been floating around in my head.
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 programming quite
difficult. This is arguable and preference for sure, but it's a major
change that could have large benefits.Make namespaces first-class meta-objects. That way, you could have
namespace private and protected classes, functions, variables, etc. This
would allow for better scoping of modules...Make all zval types pseudo-objects. Basically enabling something akin to
auto-boxing allowing a significant amount of the standard library to be
eventually deprecated in favor of acting on methods (not initially, but
opens the door).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 not saying all of them are solid. I'm not saying any of them are solid.
But hopefully this can spark a discussion around it...Thoughts?
Anthony
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.hochstrasser@gmail.com> wrote:
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 structures) to
proper
Core APIs by dropping the "SPL" prefix.- Converts all resource based APIs (file, stream,…) to Object Oriented APIs
- Maybe find a way to share the standard library between multiple
implementations
of PHP (HipHop, Quercus, Phalanger).A better parser which is more maintainable and makes it easier to implement
language features every modern programming language has.
- Slicing operators for Arrays (and Strings?)
- Splice Operator: splits an array into arguments for a function call.
Then we can finally removecall_user_func_array().- Optional Semicolons? I recently started doing some programming in Go and
I
really like this.Clean up the language:
- Remove the old array() declaration syntax.
- Replace some keywords with syntax constructs. For example remove list()
and
use multi assignment syntax like $var1, $var2 = foo(); or remove the
array()
syntax. Makes names like "List" and "Array" usable as Userspace class names
again.Remove features which were made obsolete by the SPL:
- __autoload() — was made obsolete by
spl_autoload_register()dir()— DirectoryIterator, probably makedir()just return a
DirectoryIterator.- probably more.
Make some runtime features more consistent:
- Autoloading for all kind of missing constants (function names, namespace
constants)- Function importing just like Class importing
- Language Specification which makes it easier to maintain competing
implementations.There's probably a lot more we could do, but these are some things from
right the
top of my head.--
Christoph Hochstrasser
http://twitter.com/hochchristoph | http://christophh.net |
https://github.com/CHHAm Freitag, 13. Juli 2012 um 17:33 schrieb Anthony Ferrara:
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 would be the major
changes that we'd base it on.Here are a few of the ideas that have been floating around in my head.
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 programming quite
difficult. This is arguable and preference for sure, but it's a major
change that could have large benefits.Make namespaces first-class meta-objects. That way, you could have
namespace private and protected classes, functions, variables, etc. This
would allow for better scoping of modules...Make all zval types pseudo-objects. Basically enabling something akin
to
auto-boxing allowing a significant amount of the standard library to be
eventually deprecated in favor of acting on methods (not initially, but
opens the door).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 not saying all of them are solid. I'm not saying any of them are
solid.
But hopefully this can spark a discussion around it...Thoughts?
Anthony
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
extension/compile time option, which would bring with it almost complete
backwards compatibility with PHP 5.
Dan Cryer
+Dan https://plus.google.com/101400775372325517263
@dancryer http://www.twitter.com/dancryer
On Jul 17, 2012 4:23 PM, "Christoph Hochstrasser" <
christoph.hochstrasser@gmail.com> wrote: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 structures) to
proper
Core APIs by dropping the "SPL" prefix.- Converts all resource based APIs (file, stream,…) to Object Oriented
APIs- Maybe find a way to share the standard library between multiple
implementations
of PHP (HipHop, Quercus, Phalanger).A better parser which is more maintainable and makes it easier to
implement
language features every modern programming language has.
- Slicing operators for Arrays (and Strings?)
- Splice Operator: splits an array into arguments for a function call.
Then we can finally removecall_user_func_array().- Optional Semicolons? I recently started doing some programming in Go
and
I
really like this.Clean up the language:
- Remove the old array() declaration syntax.
- Replace some keywords with syntax constructs. For example remove list()
and
use multi assignment syntax like $var1, $var2 = foo(); or remove the
array()
syntax. Makes names like "List" and "Array" usable as Userspace class
names
again.Remove features which were made obsolete by the SPL:
- __autoload() — was made obsolete by
spl_autoload_register()dir()— DirectoryIterator, probably makedir()just return a
DirectoryIterator.- probably more.
Make some runtime features more consistent:
- Autoloading for all kind of missing constants (function names,
namespace
constants)- Function importing just like Class importing
- Language Specification which makes it easier to maintain competing
implementations.There's probably a lot more we could do, but these are some things from
right the
top of my head.--
Christoph Hochstrasser
http://twitter.com/hochchristoph | http://christophh.net |
https://github.com/CHHAm Freitag, 13. Juli 2012 um 17:33 schrieb Anthony Ferrara:
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 would be the major
changes that we'd base it on.Here are a few of the ideas that have been floating around in my head..
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 programming
quite
difficult. This is arguable and preference for sure, but it's a major
change that could have large benefits.Make namespaces first-class meta-objects. That way, you could have
namespace private and protected classes, functions, variables, etc.
This
would allow for better scoping of modules...Make all zval types pseudo-objects. Basically enabling something
akin
to
auto-boxing allowing a significant amount of the standard library to be
eventually deprecated in favor of acting on methods (not initially, but
opens the door).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 not saying all of them are solid. I'm not saying any of them are
solid.
But hopefully this can spark a discussion around it...Thoughts?
Anthony
I thought list() was a syntax, not standard lib, feature? Like array() (or
am I thinking of isset()?)
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 extension/compile time option, which would bring with it almost
complete backwards compatibility with PHP 5.Dan Cryer
+Dan https://plus.google.com/101400775372325517263
@dancryer http://www.twitter.com/dancryerOn Jul 17, 2012 4:23 PM, "Christoph Hochstrasser" <
christoph.hochstrasser@gmail.com> wrote: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 structures)
to
proper
Core APIs by dropping the "SPL" prefix.- Converts all resource based APIs (file, stream,…) to Object Oriented
APIs- Maybe find a way to share the standard library between multiple
implementations
of PHP (HipHop, Quercus, Phalanger).A better parser which is more maintainable and makes it easier to
implement
language features every modern programming language has.
- Slicing operators for Arrays (and Strings?)
- Splice Operator: splits an array into arguments for a function call.
Then we can finally removecall_user_func_array().- Optional Semicolons? I recently started doing some programming in Go
and
I
really like this.Clean up the language:
- Remove the old array() declaration syntax.
- Replace some keywords with syntax constructs. For example remove
list()
and
use multi assignment syntax like $var1, $var2 = foo(); or remove the
array()
syntax. Makes names like "List" and "Array" usable as Userspace class
names
again.Remove features which were made obsolete by the SPL:
- __autoload() — was made obsolete by
spl_autoload_register()dir()— DirectoryIterator, probably makedir()just return a
DirectoryIterator.- probably more.
Make some runtime features more consistent:
- Autoloading for all kind of missing constants (function names,
namespace
constants)- Function importing just like Class importing
- Language Specification which makes it easier to maintain competing
implementations.There's probably a lot more we could do, but these are some things from
right the
top of my head.--
Christoph Hochstrasser
http://twitter.com/hochchristoph | http://christophh.net |
https://github.com/CHHAm Freitag, 13. Juli 2012 um 17:33 schrieb Anthony Ferrara:
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 would be the major
changes that we'd base it on.Here are a few of the ideas that have been floating around in my head.
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 programming
quite
difficult. This is arguable and preference for sure, but it's a major
change that could have large benefits.Make namespaces first-class meta-objects. That way, you could have
namespace private and protected classes, functions, variables, etc.
This
would allow for better scoping of modules...Make all zval types pseudo-objects. Basically enabling something
akin
to
auto-boxing allowing a significant amount of the standard library to
be
eventually deprecated in favor of acting on methods (not initially,
but
opens the door).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 not saying all of them are solid. I'm not saying any of them are
solid.
But hopefully this can spark a discussion around it...Thoughts?
Anthony
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 ajfweb@googlemail.comwrote:
I thought list() was a syntax, not standard lib, feature? Like array() (or
am I thinking of isset()?)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 extension/compile time option, which would bring with it almost
complete backwards compatibility with PHP 5.Dan Cryer
+Dan https://plus.google.com/101400775372325517263
@dancryer http://www.twitter.com/dancryerOn Jul 17, 2012 4:23 PM, "Christoph Hochstrasser" <
christoph.hochstrasser@gmail.com> wrote: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 structures)
to
proper
Core APIs by dropping the "SPL" prefix.- Converts all resource based APIs (file, stream,…) to Object Oriented
APIs- Maybe find a way to share the standard library between multiple
implementations
of PHP (HipHop, Quercus, Phalanger).A better parser which is more maintainable and makes it easier to
implement
language features every modern programming language has.
- Slicing operators for Arrays (and Strings?)
- Splice Operator: splits an array into arguments for a function call.
Then we can finally removecall_user_func_array().- Optional Semicolons? I recently started doing some programming in Go
and
I
really like this.Clean up the language:
- Remove the old array() declaration syntax.
- Replace some keywords with syntax constructs. For example remove
list()
and
use multi assignment syntax like $var1, $var2 = foo(); or remove the
array()
syntax. Makes names like "List" and "Array" usable as Userspace class
names
again.Remove features which were made obsolete by the SPL:
- __autoload() — was made obsolete by
spl_autoload_register()dir()— DirectoryIterator, probably makedir()just return a
DirectoryIterator.- probably more.
Make some runtime features more consistent:
- Autoloading for all kind of missing constants (function names,
namespace
constants)- Function importing just like Class importing
- Language Specification which makes it easier to maintain competing
implementations.There's probably a lot more we could do, but these are some things
from
right the
top of my head.--
Christoph Hochstrasser
http://twitter.com/hochchristoph | http://christophh.net |
https://github.com/CHHAm Freitag, 13. Juli 2012 um 17:33 schrieb Anthony Ferrara:
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 would be the major
changes that we'd base it on.Here are a few of the ideas that have been floating around in my
head.
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 programming
quite
difficult. This is arguable and preference for sure, but it's a
major
change that could have large benefits.Make namespaces first-class meta-objects. That way, you could
have
namespace private and protected classes, functions, variables, etc.
This
would allow for better scoping of modules...Make all zval types pseudo-objects. Basically enabling something
akin
to
auto-boxing allowing a significant amount of the standard library to
be
eventually deprecated in favor of acting on methods (not initially,
but
opens the door).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 not saying all of them are solid. I'm not saying any of them are
solid.
But hopefully this can spark a discussion around it...Thoughts?
Anthony
--
--
Brandon Wamboldt
Programmer / Web Developer
StackOverflow Careers
Profilehttp://careers.stackoverflow.com/brandonwamboldt- GitHub
Profile https://github.com/brandonwamboldt -
LinkedInhttps://github.com/brandonwamboldt -
My Blog <http://brandonwamboldt.ca/
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
extension/compile time option, which would bring with it almost complete
backwards compatibility with PHP 5.
I think any reasonable person would expect there to be a significant number
of BC breaks in any major version increment. That being said, wouldn't it
be possible in most of these cases to just do what we already do and use
the E_DEPRECATED flag? That way, people will have a reasonable amount of
time to update their code to current standards before a behavior is removed
completely.
And in cases where E_DEPRECATED
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
extension/compile time option, which would bring with it almost complete
backwards compatibility with PHP 5.I think any reasonable person would expect there to be a significant
number of BC breaks in any major version increment. That being said,
wouldn't it be possible in most of these cases to just do what we already
do and use theE_DEPRECATEDflag? That way, people will have a reasonable
amount of time to update their code to current standards before a behavior
is removed completely.And in cases where
E_DEPRECATED
Bah just had an unfortunate sequence of unintentional keystrokes....
As I was saying:
....And in cases where E_DEPRECATED wouldn't be feasible (such as with
changing function arguments), my thinking would be to just make the change
without having any legacy flags that have to be maintained. Again, it's a
major version change. Nobody should be getting butthurt over BC breaks.
If you haven't updated your code since PHP 3, for example, my answer would
be to either update your code or stick with PHP 3. The rest of us
shouldn't have to maintain inferior behavior-- especially in major version
increments-- just to accommodate those developers who refuse to keep their
code up-to-date.
--Kris