Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61204
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <CAAyV7nFQc+4fWk2+aAJ_ctpqpsJGcYMR-fsgqDvPRzD36YJggg@mail.gmail.com>
References: <CAAyV7nFQc+4fWk2+aAJ_ctpqpsJGcYMR-fsgqDvPRzD36YJggg@mail.gmail.com>
Date: Fri, 13 Jul 2012 18:12:58 +0200
Message-ID: <CAMUwpuRHfp4tFnrBHOww69G4VmvRY=9rtkxtk_iyJgodtp7Fgw@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] 6.0 And Moving Forward
From: jpauli@php.net (jpauli)

On Fri, Jul 13, 2012 at 5:33 PM, Anthony Ferrara <ircmaxell@gmail.com> wrote:
> Hey all,
>
> I know that 6.0 was originally supposed to be the unicode conversion of the
> engine. However it appears that all progress on that has stopped for quite
> some time.
>
> So, I was curious if we could start a conversation around what 6.0 would
> look like if we didn't go the unicode route. What would be the major
> changes that we'd base it on.

Will it be named 6.0 ? That's the first question.
We should, IMO, open a huge wiki page to aggregate our ideas. No
voting stuff at all for the moment, just throw ideas like you did in
this mail.
The RFC could then be split later in severals little ones if needed.
Debate like "+1"s should appear on the mailing list though. "+1"s are
just first advices, needing deeper investigation; ML is then a good
place for that.

>
> Here are a few of the ideas that have been floating around in my head.
>
> 1. Change the error handling system from the current E_* system to typed
> exceptions for everything but advisory errors (E_STRICT, E_NOTICE,
> E_DEPRECATED). Why? Because the current error system encourages ignoring or
> not checking what the error was, and it makes defensive programming quite
> difficult. This is arguable and preference for sure, but it's a major
> change that could have large benefits.
>
> 2. Make namespaces first-class meta-objects. That way, you could have
> namespace private and protected classes, functions, variables, etc. This
> would allow for better scoping of modules...
>
> 3. Make all zval types pseudo-objects. Basically enabling something akin to
> auto-boxing allowing a significant amount of the standard library to be
> eventually deprecated in favor of acting on methods (not initially, but
> opens the door).
>
> 4. Rewrite the entire parser completely. I keep hearing about how bad PHP's
> parser is, and how it's growing out of control. Perhaps this is a good time
> to rewrite it (perhaps changing semantics slightly) to be better adapted
> towards future changes...

We have an RFC and a patch playing with lemon parser. Actually, just a
conversion, reentrant.
Refer to Pierrick or Felipe about it :-)

>
> I'm not saying all of them are solid. I'm not saying any of them are solid.
> But hopefully this can spark a discussion around it...

I would have added merging the SPL code to ZendEngine, somehow.

Thanks !

Julien