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 <[email protected]>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, "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 > >> > > >> > > >> > > > > > -- *Brandon Wamboldt* Programmer / Web Developer StackOverflow Careers Profile<http://careers.stackoverflow.com/brandonwamboldt>- GitHub Profile <https://github.com/brandonwamboldt> - LinkedIn<https://github.com/brandonwamboldt> - My Blog <http://brandonwamboldt.ca/>
