Re: my take on PHP 6, part 2

Q 0 Sendt fra min iPhone > Den 17/02/2014 kl. 18.08 skrev "guilhermeblanco@gmail.com" > <guilhermeblanco@gmail.com>: > > 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