Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72660
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
To: "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>
Cc: Amaury Bouchard <amaury@amaury.net>, Pierre Joye
 <pierre.php@gmail.com>, PHP internals <internals@lists.php.net>
In-Reply-To: <CAFp73XuNchZm2MOMDVSHTaLMRSVe+gR7u=d=oWJcsWbW0z3mrw@mail.gmail.com>
References:
	 <CAEZPtU6ePFu-evVYyknBJa+0M7QZ3f9QvTeu5vvKpnNp_bkbZg@mail.gmail.com>
	 <CANgS8h9-KR=7FCZHc2W6XGN0y5HAg1fkjx2_wTvOgEm3ta4=_Q@mail.gmail.com>
	 <CAFp73XuNchZm2MOMDVSHTaLMRSVe+gR7u=d=oWJcsWbW0z3mrw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 17 Feb 2014 19:18:02 +0100
Message-ID: <1392661082.3990.265.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] my take on PHP 6, part 2
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

Hi,

On Mon, 2014-02-17 at 12:08 -0500, guilhermeblanco@gmail.com wrote:

> 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.

ZE2 is not a rewrite. PHP 5.1 or 5.2, not sure, had a completely new
executor,aside from that there mostly were extensions.

> A couple of things to motivate:
> 
>    - Native Unicode support

Complicated one, see other threads.

>    - Make opcode cache native

What does that mean? What's the expected benefit over opcache?

>    - Better garbage collector

In what sense? 

>    - Add basic support for interceptors (preConstruct, postDestroy,
>    aroundInvoke)

This can be added by extensions if needed.

>    - Operator overloading, allowing things like Comparable interface

No. Please not.

>    - Attempt to simplify language operators/keywords/symbols

A part of PHP's design is to have keywords which can be googled for,
short operators, notations make it harder if one stumbles over unknown
constructs. Any precise examples?

>    - Native ctype support (no, not the current supported one. Look for its
>    support in Python)

Not an engine feature. feel free to provide an extension API, eventually
might be bundled. (and enabled by default / force)

>    - With better opcache and ctype, also add better dl(), completely
>    removing the need to have so many extensions in core

Better dl is not trivial due to operating system restrictions. With
major refactoring we might improve this a bit, but things which come to
mind cause major breakage in APIs for quite little effect ... I thought
a while about this in regards to composer etc.

>    - Remove "global" support

Why?

>    - Errors to exceptions

Complicated one, not all errors we have can a) be recovered and b) are
actual errors. Needs a good concept (see also other thread)

>    - Consistent exception messages

Feel free to go through it and propose something, that's quite abstract.

>    - Scalar type hinting
>    - Named Parameters
>    - Annotations

See other threads.

>    - Default class resolution/loading (aka. Native PSR-0 support)

Again nothing related to the engine, if that is implemented in an
internal function for spl or such it might be added. Shouldn't be too
complex (except that user-space implementations are simpler to debug for
users if something goes wrong)

>    - Remove error suppression (@ operator)

Unless error handling is revamped this is needed.

>    - C# style mutators and accessors

See RFC.

>    - Comparable interface

See other thread.

>    - Collection, Map, Set, List, Bag

collection is a generic term, not sure what you mean. A PHP array is a
map. We have lists in SPL. A bag (multiset/multimap) can be emulated in
a nested array ... if there is need SPL could be extended.

>    - Namespace visibility
>    - Namespace Variables
>    - Namespace Reflection API

for the later we'd indeed have to refactor the engine in a way to have
more overhead from namespaces. This might also be needed in casethe
others are requested ... might need details.

>    - Drop optional property/method visibility support (make them required)

Why?

>    - Polymorphism (aka. method overloading)

Hard to do in a dynamic language in an efficient way. will slow down
each and every function call unless somebody has a good idea. Till then
we prefer extra cost for the implementor in the few times this is
needed.

>    - Virtual methods

what should this be in the context of PHP? From a C++ sense all PHP
methods are virtual.

>    - pecl_http into core (considering better dl() item isn't accepted)

might be interesting.

>    - Previous item would lead to complete removal of superglobals

Why that? To break every single PHP script out there?

>    - Normalize overall current/future design for the language (why
>    __toString, __wakeup, __sleep vs. Jsonable or Serializable interfaces?)

any proposal keeping a viable BC way?

>    - 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)

See old discussions on type hints etc.

>    - Remove functions from global namespace

Why?

>    - Threads support (no, don't tell me about pthreads extension)

for what purpose? We should imo rather focus on async operations. Doing
complex operations in parallel on a loaded web frontend doesn't seem
right, rather send tasks to backend services. Threading also adds quite
some complexity hurting single threaded scripts.

>    - Shorthand functions declaration somehow

for what purpose?

>    - Get rid of aliased functions

why?

>    - Basically apply Poka-Yoke principle to the language. There should be
>    only one way of doing a given action

This is a great goal. Not trivial if one wants to allow evolution.


Please mind: Compatibility *is* a feature. Not only for past users but
also helps to ensure new users that their investment won't be lost on
the next version. There are tons of legacy code and tons of lines being
created every second which will be legacy a second later. We can break
things where needed, but breaking just to be "cleaner" causes lots of
pain.

johannes