We could all look of what users are willing for too... there was a thread
on Reddit about it.
Here was my comment:
http://www.reddit.com/r/PHP/comments/1iw0cj/what_would_you_change_about_php_if_you_could/cb9rzw4
Here is the comment for lazy readers.
My suggestion back in 2011 was to rewrite Zend Engine to accommodate a few
things that people are considering as must-haves nowadays. Based on
history, each ZE is rewritten after every 5 years (1996 - 2001 for ZE1,
2001 - 2005 for ZE2), which hints we may be in a need to reevaluate current
code and plan support for next 5 years.
A couple of things to motivate:
- Native Unicode support
- Make opcode cache native
- Better garbage collector
- Add basic support for interceptors (preConstruct, postDestroy,
aroundInvoke)
- Operator overloading, allowing things like Comparable interface
- Attempt to simplify language operators/keywords/symbols
- Native ctype support (no, not the current supported one. Look for its
support in Python)
- With better opcache and ctype, also add better dl(), completely
removing the need to have so many extensions in core
- Remove "global" support
- Errors to exceptions
- Consistent exception messages
- Scalar type hinting
- Named Parameters
- Annotations
- Default class resolution/loading (aka. Native PSR-0 support)
- Remove error suppression (@ operator)
- C# style mutators and accessors
- Comparable interface
- Collection, Map, Set, List, Bag
- Namespace visibility
- Namespace Variables
- Namespace Reflection API
- Drop optional property/method visibility support (make them required)
- Polymorphism (aka. method overloading)
- Virtual methods
- pecl_http into core (considering better dl() item isn't accepted)
- Previous item would lead to complete removal of superglobals
- Normalize overall current/future design for the language (why
__toString, __wakeup, __sleep vs. Jsonable or Serializable interfaces?)
- Primitive types (enhance SplInt et al. and make them native, with
actual <type>_* required methods and discard nice to have ones)
- Add valuable to these primitive types (oh, and make the default
parameter ordering. Not everyone would love to keep using named parameters
over and over)
- Make native functions support Spl* instances (ie.: substr(new
SplString('foobar'), 0, 3)) as a beginning to remove overall functions
support
- "Strict" variable types (relies on previous 2: type hinting, type
inference, type casting, return types. Quotes were added because they would
be inferred, not declared. That would force assignments to validate types,
such as $a =1; $a=false; would throw an exception because you're changing
variable type)
- Remove functions from global namespace
- Threads support (no, don't tell me about pthreads extension)
- Shorthand functions declaration somehow
- Get rid of aliased functions
- Basically apply Poka-Yoke principle to the language. There should be
only one way of doing a given action
Hm... I think that's enough for now! =)
Cheers,
On Mon, Feb 17, 2014 at 5:39 AM, Amaury Bouchard <[email protected]> wrote:
> Before opening a new thread about JIT, I have one simple question.
> The wiki page created by Pierre talks about LibJIT. This library has an
> integrated interpreter (for platforms where JIT is not available). I don't
> know anything about the speed of this interpreter, but maybe it could be
> interresting to evaluate it as the lone interpreter in the PHP engine. Is
> anyone thinked about that?
>
>
> 2014-02-17 7:28 GMT+01:00 Pierre Joye <[email protected]>:
>
> > hi,
> >
> > I put my thoughts and summary of the recent discussions about what
> > could be PHP 6 here:
> >
> > https://wiki.php.net/ideas/php6
> >
> > Things like "we should name it php7" has not been covered, for one
> > obvious reasons.
> >
> > It is not a TODO list but a list of proposals I would like to see us
> > discuss, work on, push harder. They are features, changes, etc. I have
> > been hearing for years and things we should really give more
> > attention.
> >
> > Please do not mass reply to this thread but prefer to create one new
> > thread per topic. Who knows, we may get enough input to create one
> > wiki page per topic. And if you are lucky enough, we may even have
> > some working groups for each of them?
> >
> > Happy reading, comments, feedback and the likes welcome!
> >
> >
> > Cheers,
> > --
> > Pierre
> >
> > @pierrejoye | http://www.libgd.org
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
--
Guilherme Blanco
MSN: [email protected]
GTalk: guilhermeblanco
Toronto - ON/Canada