Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61334
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 74.125.82.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5004B10A.8070504@gmail.com>
References: <CAAyV7nFQc+4fWk2+aAJ_ctpqpsJGcYMR-fsgqDvPRzD36YJggg@mail.gmail.com>
	<5004B10A.8070504@gmail.com>
Date: Tue, 17 Jul 2012 08:40:10 +0100
Message-ID: <CAN+gjSe7bjxDv41Ye8RW4XignWL84SpL3JkbJ1d8XBzgsE+YbA@mail.gmail.com>
To: David Muir <davidkmuir@gmail.com>
Cc: internals@lists.php.net, Anthony Ferrara <ircmaxell@gmail.com>
Content-Type: multipart/alternative; boundary=f46d043c7d14f73cb104c501a7a0
Subject: Re: [PHP-DEV] 6.0 And Moving Forward
From: ajfweb@googlemail.com (Andrew Faulds)

--f46d043c7d14f73cb104c501a7a0
Content-Type: text/plain; charset=UTF-8

That would be nice and all, but I'd rather we add methods to arrays.
On Jul 17, 2012 1:26 AM, "David Muir" <davidkmuir@gmail.com> wrote:

> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--f46d043c7d14f73cb104c501a7a0--