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/>