Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61329
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
Message-ID: <5004B10A.8070504@gmail.com>
Date: Tue, 17 Jul 2012 10:25:46 +1000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: Anthony Ferrara <ircmaxell@gmail.com>
CC: internals@lists.php.net
References: <CAAyV7nFQc+4fWk2+aAJ_ctpqpsJGcYMR-fsgqDvPRzD36YJggg@mail.gmail.com>
In-Reply-To: <CAAyV7nFQc+4fWk2+aAJ_ctpqpsJGcYMR-fsgqDvPRzD36YJggg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] 6.0 And Moving Forward
From: davidkmuir@gmail.com (David Muir)

On 14/07/12 01:33, Anthony Ferrara 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.
>
> 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...
>
> 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...
>
> Thoughts?
>
> Anthony
>

I'd *really* like to see the following being possible:

$array = array('foo' => 'bar');
$object = (object) $array;

echo $array['foo']; //bar
echo $array->foo; //bar

echo $object['foo']; //bar
echo $object->foo; //bar

Is there a technical reason for the difference that currently exists?

Cheers,
David