Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61362
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 74.125.82.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <DEA06CDBC7954435A74980C291F5F150@gmail.com>
References: <CAAyV7nFQc+4fWk2+aAJ_ctpqpsJGcYMR-fsgqDvPRzD36YJggg@mail.gmail.com>
	<DEA06CDBC7954435A74980C291F5F150@gmail.com>
Date: Tue, 17 Jul 2012 16:32:15 +0100
Message-ID: <CAN+gjSc=1fDHZHmJUya+QsDDdFOsbUr8CYhMVpFBV=qOOxGRQg@mail.gmail.com>
To: Christoph Hochstrasser <christoph.hochstrasser@gmail.com>
Cc: internals@lists.php.net, Anthony Ferrara <ircmaxell@gmail.com>
Content-Type: multipart/alternative; boundary=f46d0444813545b04e04c50840e3
Subject: Re: [PHP-DEV] 6.0 And Moving Forward
From: ajfweb@googlemail.com (Andrew Faulds)

--f46d0444813545b04e04c50840e3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.
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 Ori=
ented 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 impleme=
nt
> 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 an=
d
> 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 nam=
es
> 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, namespac=
e
> 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 from
> 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 woul=
d
> > 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 type=
d
> > exceptions for everything but advisory errors (E_STRICT, E_NOTICE,
> > E_DEPRECATED). Why? Because the current error system encourages ignorin=
g
> or
> > not checking what the error was, and it makes defensive programming qui=
te
> > 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. Thi=
s
> > would allow for better scoping of modules...
> >
> > 3. Make all zval types pseudo-objects. Basically enabling something aki=
n
> 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 adapte=
d
> > 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
>
>

--f46d0444813545b04e04c50840e3--