Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61363
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: <CAHHg72Ux+r41ApJWYUL5tO4vkKwrJAdbt+22zMNdRbX8X68LqA@mail.gmail.com>
References: <CAAyV7nFQc+4fWk2+aAJ_ctpqpsJGcYMR-fsgqDvPRzD36YJggg@mail.gmail.com>
	<DEA06CDBC7954435A74980C291F5F150@gmail.com>
	<CAN+gjSc=1fDHZHmJUya+QsDDdFOsbUr8CYhMVpFBV=qOOxGRQg@mail.gmail.com>
	<CAHHg72Ux+r41ApJWYUL5tO4vkKwrJAdbt+22zMNdRbX8X68LqA@mail.gmail.com>
Date: Tue, 17 Jul 2012 17:00:15 +0100
Message-ID: <CAN+gjScqgBWDvm12zDLaj_zyk+KYYmK4CMg1E3K+gN42tNhd7A@mail.gmail.com>
To: Dan Cryer <dan@dancryer.com>
Cc: internals@lists.php.net, Anthony Ferrara <ircmaxell@gmail.com>, 
	Christoph Hochstrasser <christoph.hochstrasser@gmail.com>
Content-Type: multipart/alternative; boundary=e0cb4e43cff1699d9304c508a4f9
Subject: Re: [PHP-DEV] 6.0 And Moving Forward
From: ajfweb@googlemail.com (Andrew Faulds)

--e0cb4e43cff1699d9304c508a4f9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I thought list() was a syntax, not standard lib, feature? Like array() (or
am I thinking of isset()?)
On Jul 17, 2012 4:48 PM, "Dan Cryer" <dan@dancryer.com> wrote:

> The problem, of course, is changing and removing things can break BC. I'd
>> love to remove list() too, but that would break code relying on it.
>
>
> Isn't that kind of the point of the whole discussion? This is talking
> about completely rewriting the standard library for PHP 6, but providing =
a
> legacy extension/compile time option, which would bring with it almost
> complete backwards compatibility with PHP 5.
>
>
> *Dan Cryer*
>  +Dan <https://plus.google.com/101400775372325517263>
>  @dancryer <http://www.twitter.com/dancryer>
>
>
>
> On 17 July 2012 16:32, Andrew Faulds <ajfweb@googlemail.com> wrote:
>
>>
>> On Jul 17, 2012 4:23 PM, "Christoph Hochstrasser" <
>> christoph.hochstrasser@gmail.com> wrote:
>>
>> > Hi,
>> >
>> > Some of the things I want to see in PHP 6:
>> >
>> > New designed Standard Library:
>> >
>> > * Clearly defined conventions for organization, naming and error
>> handling.
>> > * Use Namespaces and groups functions by their purpose ("net",
>> "strings",
>> > "arrays",=E2=80=A6)
>> > * Promote SPL functionality ("spl_autoload_register", Data structures)
>> to
>> > proper
>> > Core APIs by dropping the "SPL" prefix.
>> > * Converts all resource based APIs (file, stream,=E2=80=A6) to Object =
Oriented
>> APIs
>> > * Maybe find a way to share the standard library between multiple
>> > implementations
>> > of PHP (HipHop, Quercus, Phalanger).
>> >
>> > A better parser which is more maintainable and makes it easier to
>> implement
>> > language features every modern programming language has.
>> >
>> > * Slicing operators for Arrays (and Strings?)
>> > * Splice Operator: splits an array into arguments for a function call.
>> > Then we can finally remove call_user_func_array().
>> > * Optional Semicolons? I recently started doing some programming in Go
>> and
>> > I
>> > really like this.
>> >
>> > Clean up the language:
>> >
>> > * Remove the old array() declaration syntax.
>> > * Replace some keywords with syntax constructs. For example remove
>> list()
>> > and
>> > use multi assignment syntax like $var1, $var2 =3D foo(); or remove the
>> > array()
>> > syntax. Makes names like "List" and "Array" usable as Userspace class
>> names
>> > again.
>> >
>> > Remove features which were made obsolete by the SPL:
>> >
>> > * __autoload() =E2=80=94 was made obsolete by spl_autoload_register()
>> > * dir() =E2=80=94 DirectoryIterator, probably make dir() just return a
>> > DirectoryIterator.
>> > * probably more.
>> >
>> > Make some runtime features more consistent:
>> >
>> > * Autoloading for all kind of missing constants (function names,
>> namespace
>> > constants)
>> > * Function importing just like Class importing
>> > * Language Specification which makes it easier to maintain competing
>> > implementations.
>> >
>> > There's probably a lot more we could do, but these are some things fro=
m
>> > right the
>> > top of my head.
>> >
>> >
>> >
>> > --
>> > Christoph Hochstrasser
>> > http://twitter.com/hochchristoph | http://christophh.net |
>> > https://github.com/CHH
>> >
>> >
>> >
>> > Am Freitag, 13. Juli 2012 um 17:33 schrieb Anthony Ferrara:
>> >
>> > > 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 hea=
d.
>> > >
>> > > 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 majo=
r
>> > > change that could have large benefits.
>> > >
>> > > 2. Make namespaces first-class meta-objects. That way, you could hav=
e
>> > > 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 ba=
d
>> > PHP's
>> > > parser is, and how it's growing out of control. Perhaps this is a go=
od
>> > 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
>> >
>> >
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>> >
>>
>
>

--e0cb4e43cff1699d9304c508a4f9--