> > 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 17 July 2012 16:32, Andrew Faulds <ajf...@googlemail.com> wrote: > > On Jul 17, 2012 4:23 PM, "Christoph Hochstrasser" < > christoph.hochstras...@gmail.com> wrote: > > > Hi, > > > > Some of the things I want to see in PHP 6: > > > > New designed 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: > > > > > 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 > > > > > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > >
