Q
0
Sendt fra min iPhone
> Den 17/02/2014 kl. 18.08 skrev "[email protected]"
> <[email protected]>:
>
> 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