Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61365
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)
MIME-Version: 1.0
In-Reply-To: <CAN+gjScqgBWDvm12zDLaj_zyk+KYYmK4CMg1E3K+gN42tNhd7A@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> <CAN+gjScqgBWDvm12zDLaj_zyk+KYYmK4CMg1E3K+gN42tNhd7A@mail.gmail.com>
Date: Tue, 17 Jul 2012 13:23:40 -0300
Message-ID: <CAL9B3uwqducA55dQFyT9n+-QncowZx07X-0HrTc=nrS6X=2B0Q@mail.gmail.com>
To: Andrew Faulds <ajfweb@googlemail.com>
Cc: Dan Cryer <dan@dancryer.com>, internals@lists.php.net, 
	Anthony Ferrara <ircmaxell@gmail.com>, 
	Christoph Hochstrasser <christoph.hochstrasser@gmail.com>
Content-Type: multipart/alternative; boundary=0015173fe992521a0504c508f959
Subject: Re: [PHP-DEV] 6.0 And Moving Forward
From: brandon.wamboldt@gmail.com (Brandon Wamboldt)

--0015173fe992521a0504c508f959
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

You're correct, list() is a language construct. Is it still possible to add
that in via an extension somehow?

On Tue, Jul 17, 2012 at 1:00 PM, Andrew Faulds <ajfweb@googlemail.com>wrote=
:

> I thought list() was a syntax, not standard lib, feature? Like array() (o=
r
> 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 providin=
g
> 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",=85)
> >> > * Promote SPL functionality ("spl_autoload_register", Data structure=
s)
> >> to
> >> > proper
> >> > Core APIs by dropping the "SPL" prefix.
> >> > * Converts all resource based APIs (file, stream,=85) to Object Orie=
nted
> >> 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 cal=
l.
> >> > 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 t=
he
> >> > array()
> >> > syntax. Makes names like "List" and "Array" usable as Userspace clas=
s
> >> names
> >> > again.
> >> >
> >> > Remove features which were made obsolete by the SPL:
> >> >
> >> > * __autoload() =97 was made obsolete by spl_autoload_register()
> >> > * dir() =97 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
> 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 conversi=
on
> >> of
> >> > the
> >> > > engine. However it appears that all progress on that has stopped f=
or
> >> > 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 maj=
or
> >> > > 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 programmin=
g
> >> 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 somethin=
g
> >> 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 a=
re
> >> > 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
> >> >
> >> >
> >>
> >
> >
>



--=20
*Brandon Wamboldt*
Programmer / Web Developer

StackOverflow Careers
Profile<http://careers.stackoverflow.com/brandonwamboldt>- GitHub
Profile <https://github.com/brandonwamboldt> -
LinkedIn<https://github.com/brandonwamboldt> -
My Blog <http://brandonwamboldt.ca/>

--0015173fe992521a0504c508f959--