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