Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61360
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.42 as permitted sender)
Date: Tue, 17 Jul 2012 17:23:01 +0200
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: internals@lists.php.net
Message-ID: <DEA06CDBC7954435A74980C291F5F150@gmail.com>
In-Reply-To: <CAAyV7nFQc+4fWk2+aAJ_ctpqpsJGcYMR-fsgqDvPRzD36YJggg@mail.gmail.com>
References: <CAAyV7nFQc+4fWk2+aAJ_ctpqpsJGcYMR-fsgqDvPRzD36YJggg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Subject: Re: [PHP-DEV] 6.0 And Moving Forward
From: christoph.hochstrasser@gmail.com (Christoph Hochstrasser)

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 (=22net=22, =22str=
ings=22, =22arrays=22,=E2=80=A6)
* Promote SPL functionality (=22spl=5Fautoload=5Fregister=22, Data struct=
ures) to proper
Core APIs by dropping the =22SPL=22 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 impleme=
ntations
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=3F)
* Splice Operator: splits an array into arguments for a function call.
Then we can finally remove call=5Fuser=5Ffunc=5Farray().
* Optional Semicolons=3F 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. =46or example remove list=
() and
use multi assignment syntax like =24var1, =24var2 =3D foo(); or remove th=
e array()
syntax. Makes names like =22List=22 and =22Array=22 usable as Userspace c=
lass names
again.

Remove features which were made obsolete by the SPL:

* =5F=5Fautoload() =E2=80=94 was made obsolete by spl=5Fautoload=5Fregist=
er()
* dir() =E2=80=94 DirectoryIterator, probably make dir() just return a Di=
rectoryIterator.
* probably more.

Make some runtime features more consistent:

* Autoloading for all kind of missing constants (function names, namespac=
e constants)
* =46unction importing just like Class importing
* Language Specification which makes it easier to maintain competing impl=
ementations.

There's probably a lot more we could do, but these are some things from r=
ight the
top of my head.



-- =20
Christoph Hochstrasser
http://twitter.com/hochchristoph =7C http://christophh.net =7C https://gi=
thub.com/CHH



Am =46reitag, 13. Juli 2012 um 17:33 schrieb Anthony =46errara:

> Hey all,
> =20
> 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 qu=
ite
> some time.
> =20
> 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.
> =20
> Here are a few of the ideas that have been floating around in my head.
> =20
> 1. Change the error handling system from the current E=5F* system to ty=
ped
> exceptions for everything but advisory errors (E=5FSTRICT, E=5FNOTICE,
> E=5FDEPRECATED). Why=3F Because the current error system encourages ign=
oring 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.
> =20
> 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...
> =20
> 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).
> =20
> 4. Rewrite the entire parser completely. I keep hearing about how bad P=
HP'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...
> =20
> I'm not saying all of them are solid. I'm not saying any of them are so=
lid.
> But hopefully this can spark a discussion around it...
> =20
> Thoughts=3F
> =20
> Anthony =20