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" <[email protected]> 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 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 <[email protected]> wrote: > >> >> On Jul 17, 2012 4:23 PM, "Christoph Hochstrasser" < >> [email protected]> 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 >> > >> > >> > >
