Re: my take on PHP 6, part 2

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 <amaury@amaury.net> 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 <pierre.php@gmail.com>: > > > 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: guilhermeblanco@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada