# 6.0 And Moving Forward - Thread: https://externals.io/message/61201 - Original archive: https://news-web.php.net/php.internals/61201 - Started by Anthony Ferrara on 2012-07-13T15:33:25+00:00 - Messages: 25 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #61201 — Anthony Ferrara — 2012-07-13T15:33:25+00:00 URL: https://externals.io/message/61201#61201 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. 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 programming quite difficult. This is arguable and preference for sure, but it's a major change that could have large benefits. 2. 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... 3. 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). 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 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 --- ## #61202 — Ryan McCue — 2012-07-13T16:02:40+00:00 URL: https://externals.io/message/61201#61202 · In reply to: #61201 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 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). > 3. 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 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. > > 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 programming quite > difficult. This is arguable and preference for sure, but it's a major > change that could have large benefits. > > 2. 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... > > 3. 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). > > 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... 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 --- ## #61206 — Kris Craig — 2012-07-13T16:47:14+00:00 URL: https://externals.io/message/61201#61206 · In reply to: #61201 > > > 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 hornet's nest: Anyone up for converting the whole damn thing to C++? I welcome your hatred. Muaa ha ha ha! ;) --Kris --- ## #61207 — Lester Caine — 2012-07-13T16:50:20+00:00 URL: https://externals.io/message/61201#61207 · In reply to: #61201 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?' > 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 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 --- ## #61209 — Stas Malyshev — 2012-07-13T17:23:00+00:00 URL: https://externals.io/message/61201#61209 · In reply to: #61207 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 --- ## #61221 — Sherif Ramadan — 2012-07-14T06:14:44+00:00 URL: https://externals.io/message/61201#61221 · In reply to: #61209 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. --- ## #61222 — Pierre Joye — 2012-07-14T09:40:56+00:00 URL: https://externals.io/message/61201#61222 · In reply to: #61221 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 --- ## #61223 — Lester Caine — 2012-07-14T10:03:32+00:00 URL: https://externals.io/message/61201#61223 · In reply to: #61221 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 --- ## #61225 — Clint Priest — 2012-07-14T11:47:34+00:00 URL: https://externals.io/message/61201#61225 · In reply to: #61206 +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 > > > […] > 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 --- ## #61279 — Ralf Lang — 2012-07-16T09:25:08+00:00 URL: https://externals.io/message/61201#61279 · In reply to: #61201 -----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 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 --- ## #61281 — Andrew Faulds — 2012-07-16T09:36:20+00:00 URL: https://externals.io/message/61201#61281 · In reply to: #61279 Yeah, we could do something like Java: primitive typed and OOP wrapped types. > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > […] > > > 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. > > > […] > > 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 --- ## #61329 — David Muir — 2012-07-17T00:25:46+00:00 URL: https://externals.io/message/61201#61329 · In reply to: #61201 > 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. > > 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 programming quite > difficult. This is arguable and preference for sure, but it's a major > change that could have large benefits. > > 2. 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... > > 3. 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). > > 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 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 --- ## #61332 — Nicholas Curtis — 2012-07-17T03:40:08+00:00 URL: https://externals.io/message/61201#61332 · In reply to: #61279 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 > > > […] > > > 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. > > > […] > > 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 --- ## #61334 — Andrew Faulds — 2012-07-17T07:40:10+00:00 URL: https://externals.io/message/61201#61334 · In reply to: #61329 That would be nice and all, but I'd rather we add methods to arrays. > > > > […] > 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 --- ## #61337 — Thomas Nunninger — 2012-07-17T09:07:42+00:00 URL: https://externals.io/message/61201#61337 · In reply to: #61332 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.0 > > While 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 " > 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 wrote: > Hi, > > > > > […] > > The idea to separate old and new behaviour has some charm. > > > > […] > $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 " " 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 Profile- GitHub Profile - LinkedIn - My Blog 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. > > 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 programming quite > difficult. This is arguable and preference for sure, but it's a major > change that could have large benefits. > > 2. 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... > > 3. 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). > > 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 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 --- ## #61362 — Andrew Faulds — 2012-07-17T15:32:15+00:00 URL: https://externals.io/message/61201#61362 · In reply to: #61360 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 remove `call_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 make `dir()` 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: > > > […] > the > > […] > quite > > […] > or > > […] > to > > […] > PHP's > > […] > time > > […] > solid. > > […] --- ## #61364 — Dan Cryer — 2012-07-17T15:48:14+00:00 URL: https://externals.io/message/61201#61364 · In reply to: #61362 > > 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 @dancryer > > On Jul 17, 2012 4:23 PM, "Christoph Hochstrasser" < > christoph.hochstrasser@gmail.com> wrote: > > > […] > handling. > > […] > APIs > > […] > implement > > […] > and > > […] > names > > […] > namespace > > […] > would > > […] > typed > > […] > ignoring > > […] > quite > > […] > This > > […] > akin > > […] > adapted > > […] --- ## #61363 — Andrew Faulds — 2012-07-17T16:00:15+00:00 URL: https://externals.io/message/61201#61363 · In reply to: #61364 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 > > […] > > > 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 > @dancryer > > > > > > > […] --- ## #61365 — Brandon Wamboldt — 2012-07-17T16:23:40+00:00 URL: https://externals.io/message/61201#61365 · In reply to: #61363 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()?) > > > > […] > a > > […] > from > > […] > head. > > […] > major > > […] > have > > […] > bad > > […] > good > > […] > -- *Brandon Wamboldt* Programmer / Web Developer StackOverflow Careers Profile- GitHub Profile - LinkedIn - My Blog > […] > > > 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 --- ## #61382 — Kris Craig — 2012-07-17T22:47:17+00:00 URL: https://externals.io/message/61201#61382 · In reply to: #61381 > > > > > > […] > 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` > 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 --- ## #61554 — Derick Rethans — 2012-07-20T10:05:13+00:00 URL: https://externals.io/message/61201#61554 · In reply to: #61209 > > […] > > 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