Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31957
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 63.205.162.114 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 28 Aug 2007 20:32:53 -0700
Message-ID: <698DE66518E7CA45812BD18E807866CE9AAFB9@us-ex1.zend.net>
Thread-Topic: [PHP-DEV] What should be in 5.3?
Thread-Index: AcfojaD+RZqLZRhdSniDIjF9hEFfJQBXmCLw
References: <46D299AE.6000404@pooteeweet.org>
To: "Lukas Kahwe Smith" <mls@pooteeweet.org>,
	"PHP Developers Mailing List" <internals@lists.php.net>
Subject: RE: [PHP-DEV] What should be in 5.3?
From: andi@zend.com ("Andi Gutmans")

Hi all,

From my point of view I think we can make a really good PHP 5.3 release
pretty quickly as long as we are careful about the scope. There's a lot
of good work which is low risk which we can easily roll into it. There
are high risk items like garbage collection etc. which I think we should
continue working on, etc. but target them more towards PHP 6. Adding
such features into a PHP 5.3 branch wouldn't allow us to release that
for a long time. I think schedule wise it's not unreasonable to do a
pretty feature rich PHP 5.3 beta in November and release in January. I
prefer the release-early, release-often mantra and that'll require us to
somewhat be careful about the scope and high risk items.

The following are some suggestions we (Dmitry, Stas and I) have re:
items we had on our lists. We divided them into what we think are
must-haves (i.e. don't release without), should-haves (we should try to
get these in but they wouldn't be show stoppers for release), and nice
to-haves (low priority).

Must have:
These are ones that we'd really like to be in 5.3 and think should delay
5.3 release if they aren't ready.
   1. ICU extension
   2. OpenSSL modifications for OpenID
   3. Dynamic class access ($class::method)
   4. (binary) operator which is the same as (string)
   5. remove --enable-fastcgi and family, always enable them
   6. __callStatic & friends
   7. remove warning for var=20

Should have:
These are ones that we'd like to be in 5.3, but if there are problems
with them we are ready to go without them and catch up in 5.3.x, 5.4,
etc.
   1. Unicode extension (normalization, character properties, etc.)
   2. Late static binding
   3. Namespaces (still needs maturing so that will be the main factor
for deciding if in or out)
   4. Make memory manager pluggable per-request (simple patch)
   5. Synchronize all OO module docs to look the same (PHPDOC team)
   6. remove undocumented support for strings in list($a,$b) =3D "ab"
   7. Move arg_info and other C constants from .data to .text (or
.rdata) segment
   8. Non-parsed heredocs (nowdocs)=20

Nice to have:
These are ones that we'd like to have in 5.3, but are not important
enough to spend energy on before first two groups are achieved (unless
of course somebody has a good working implementation).

   1. cookie2 support
   2. stat cache for windows/unix
   3. mysqlnd
   4. goto
   5. __construct in interfaces
   6. Compiled functions (CFs) and classes in PHP
   7. Allow parser to evaluate static expressions (-1, 2+2) in
compile-time (it won't work with constants (X+1))

Our 2 cents.
Andi

> -----Original Message-----
> From: Lukas Kahwe Smith [mailto:mls@pooteeweet.org]
> Sent: Monday, August 27, 2007 2:30 AM
> To: PHP Developers Mailing List
> Subject: [PHP-DEV] What should be in 5.3?
>=20
> Hi,
>=20
> In the spirit of forwards compabitility I think the 5.3 release will
we
> very important regardless if we keep or remove the unicode switch in
> PHP6. From my POV 5.1 and 5.2 have mainly covered stability and
> performance improvements on top of the addition of several important
> extensions like PDO, Json etc.
>=20
> In terms of changes to the actual language the main thing that sticks
> in
> my head where things like E_STRICT and is_a vs. instanceOf. So now
with
> 5.3 we might want to look ahead towards PHP6 and make sure that we add
> whatever makes sense to have in 5.x that will ease the life for people
> writing forward compatible code for PHP6. It might also be a chance to
> revisit the question of how we want to approach strictness and
> deprecation.
>=20
> Forward compatibility:
> - binary cast
> - namespaces
> - ...
>=20
> Strictness:
> - What is our philisophy, is OO more strict than procedural or is
there
> no such differntiation? I remember the discussions about dynamic
member
> variables, number incrementing throwing notices inconsistently,
> signature rewriting. I fear I am opening a can of worms with this one.
> Although I disagree with the bulk of the decisions on this topic in
the
> past I am not trying to reopen the discussions, I just hope to get a
> clearer definition on our philosiphie for future discussions
>=20
> Deprecation:
> - Split of deprecation from E_STRICT
> - Rule for deprecation
>=20
> See the todo wiki for some hints on things currently planned (or that
I
> heard people thinking about planning):
>=20
> http://oss.backendmedia.com/PhP53
> http://oss.backendmedia.com/PhP60
>=20
> regards,
> Lukas
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php