Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72658
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CANgS8h9-KR=7FCZHc2W6XGN0y5HAg1fkjx2_wTvOgEm3ta4=_Q@mail.gmail.com>
References: <CAEZPtU6ePFu-evVYyknBJa+0M7QZ3f9QvTeu5vvKpnNp_bkbZg@mail.gmail.com>
 <CANgS8h9-KR=7FCZHc2W6XGN0y5HAg1fkjx2_wTvOgEm3ta4=_Q@mail.gmail.com>
Date: Mon, 17 Feb 2014 12:08:11 -0500
Message-ID: <CAFp73XuNchZm2MOMDVSHTaLMRSVe+gR7u=d=oWJcsWbW0z3mrw@mail.gmail.com>
To: Amaury Bouchard <amaury@amaury.net>
Cc: Pierre Joye <pierre.php@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01182bb47fb54f04f29d3492
Subject: Re: [PHP-DEV] my take on PHP 6, part 2
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

--089e01182bb47fb54f04f29d3492
Content-Type: text/plain; charset=UTF-8

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

--089e01182bb47fb54f04f29d3492--