Hi all,
recently there were quite a few proposals about stuff for 5.3. If we implement
them all we won't finish in a "soonish" time and we get new ideas postponing
the 5.3 release therefore the following:
-
Scanner based on re2c:
Going to re2c promises to make maintenance simpler and increase the parsers
performance. Currently the prototype does not provide support for Zend
multibyte mode. This seems doable within April. Hence I ask for finishing
by end of April the latest. Once that is done we will go over to a freeze and
switch to bug fixing only mode.
If this is done sooner than we'll freeze sooner, too. If there are delays
we'll freeze anyways and use the scanner for a later release. -
bundling pecl/intl
According to Stas it's ready for being bundled and was voted in. The only
question I see there is the "how to bundle it". There we should definitely
find a better thing than symlinking around on the CVS server, an option
might be to to switch to subversion and use svn:externals or keeping stuff
in pecl and then having some scripts (maybe part of buildconf/the release
scripts) fetching them into a checkout. Just ideas ... For the moment
symlinking might be the best. -
bundling pecl/phar
Lots of work has been done there, I'd like to have it in, general PECL
discussion: See above. -
Large File Support
That's a thing on the todo for ages. A patch was proposed by Wez once[1]. The
patch should be, according to Wez, improved to use php_config.h for the
defines instead of passing them using CFLAGS. Additionally one should mind
Joe's comments[2] in that old thread. If somebody has time I'd welcome it, if
not: It waited for so long already so it might wait a bit more. ;-)[1] internals@lists.php.net/msg31117" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg31117
[2] internals@lists.php.net/msg31124" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg31124 -
All the other stuff
Extension maintainers always like improving their extensions, There will be
improvements to GD I think and other stuff, I don't list that all - the
timeline is mentioned above. -
Fixes&Testing
Test snaps, report bugs, fix bugs, ... That's the most important thing. That's
where really everybody reading this can contribute and do important things. :-)
You might miss some stuff in the list above, at first one might think about
these:
-
Traits: Interesting concept, basically most of us want it, some decision
about some details needed, then some implementation, i had a short discussion
with Stefan and we agreed that we don't call it "release critical" for 5.3 and
plan 5.3 without traits. -
Closures/Anonymous functions: Basically the same as with traits, some detail
discussions left, then a bit time for updating the patches, not planned for 5.3.
Surrounding all this stuff we'd also have another topic we should start
working on:
Updating guide, something like README.UPDATE_5_2. I think our new wiki
might be a good place to create such a list. I'll find some place there
and come than back to the list, but you might already start thinking
about stuff you know that should be mentioned there. That's again a
thing everybody can contribute.
That's enough for the moment,
johannes
PHP 5.3 RM
Hello Johannes,
Thursday, March 6, 2008, 6:10:27 PM, you wrote:
Hi all,
recently there were quite a few proposals about stuff for 5.3. If we implement
them all we won't finish in a "soonish" time and we get new ideas postponing
the 5.3 release therefore the following:
- Scanner based on re2c:
[...]
Anyone interested more in this one might
a) have a look here: http://blog.somabo.de/2008/02/php-on-re2c.html
b) provide tests for configure --enable-zend-multibyte (and whatever you
use it for)
Best regards,
Marcus
Hi all,
recently there were quite a few proposals about stuff for 5.3. If we implement
them all we won't finish in a "soonish" time and we get new ideas postponing
the 5.3 release therefore the following:
I'd like to ask to re-consider dropping ze1_compatibility_mode and finally drop it in 5.3.
It just doesn't work, so there is no point to keep it.
--
Wbr,
Antony Dovgal
2008/3/6, Antony Dovgal tony@daylessday.org:
It just doesn't work, so there is no point to keep it.
That statement is very true, it does not work at all.
Also will be nice if zend.enable_gc ini setting is dropped as well
before it is too late , having yet another ini setting that alters the
engine behaviuor looks pretty much like the repeating the same old
mistakes over and over again.
either GC or dont, please.
--
"If debugging is the process of removing bugs, then programming must
be the process of putting them in." – Edsger Dijkstra
Hi!
Also will be nice if zend.enable_gc ini setting is dropped as well
before it is too late , having yet another ini setting that alters the
engine behaviuor looks pretty much like the repeating the same old
mistakes over and over again.
Does it alter the engine behaviour? I was under impression the behavior
is the same, just the moment when memory is reclaimed has changed. Does
it mean there's code that works differently with GC than without?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
-----Original Message-----
From: Cristian Rodriguez [mailto:judas.iscariote@gmail.com]
Sent: Thursday, March 06, 2008 10:03 AM
To: php-dev
Subject: Re: [PHP-DEV] 5.3 Release PlanningAlso will be nice if zend.enable_gc ini setting is dropped as well
before it is too late , having yet another ini setting that alters the
engine behaviuor looks pretty much like the repeating the same old
mistakes over and over again.either GC or dont, please.
There is no functional implication and you will see the same behavior (except for memory usage and performance). Also I think we agreed this would not be a phpinfo() INI setting but one we can turn off for debugging purposes because until it's completely stable there may be GC bugs (we've had several). Also during the rollout process it'll help us triage performance issues if they come up (Turn it off and let us know if you feel a difference). Of course the bookkeeping is always on.
So suggest to keep it in, not in phpinfo() and see how things roll out.
Andi
-----Original Message-----
From: Antony Dovgal [mailto:tony@daylessday.org]
Sent: Thursday, March 06, 2008 9:36 AM
To: Johannes Schlüter
Cc: PHP Internals List
Subject: Re: [PHP-DEV] 5.3 Release PlanningI'd like to ask to re-consider dropping ze1_compatibility_mode and
finally drop it in 5.3.
It just doesn't work, so there is no point to keep it.
Yes I think it makes sense.
Do we just document it in the UPGRADING doc or for 5.3 raise an E_ERROR with an error message? s
I'd like to ask to re-consider dropping ze1_compatibility_mode and
finally drop it in 5.3.
It just doesn't work, so there is no point to keep it.Yes I think it makes sense.
Do we just document it in the UPGRADING doc or for 5.3 raise anE_ERRORwith an error message? s
No errors, please.
Just a warning in the docs and in the official announcement.
--
Wbr,
Antony Dovgal
- bundling pecl/intl
According to Stas it's ready for being bundled and was voted in. The only
Most of it is ready, since 5.3 took more time that we initially thought
we also added dateformatter functionality there, which right now has
last wrinkles straightened out - code is mostly complete, docs in the
works, there might be minor API optimizations and bugfixes, but in
general we could certainly merge it by the end of April. I don't want to
symlink it until we have the code 100% done, but we are very close.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
i just hope the issue described in
internals@lists.php.net/msg32601.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg32601.html will
be resolved before 5.3 is out. it is the only problem that breaks
opcode cacher support as far as i can see by now. e.g.: with this
problem fixed, all test cases will pass when XCache is enabled but not
without fixed
Hi all,
recently there were quite a few proposals about stuff for 5.3. If we
implement
them all we won't finish in a "soonish" time and we get new ideas
postponing
the 5.3 release therefore the following:
One thing that never really was resolved were the patches I submitted as a
compromise to some of the early disagreements about late static binding.
http://marc.info/?l=php-internals&m=119605755711936&w=2
There was a little bit of discussion but it was quickly overshadowed by talk
of brackets, imports, and other things. I don't necessarily think all of the
arguments need to be rehashed again as they have been beaten to death, it
would just be good to get an actual decision on whether or not one of them
(hopefully the parent:: one) can make it in.
If so I can update whichever patch.
Hi Mike,
Am Sonntag, den 09.03.2008, 21:52 -0700 schrieb Mike Lively:
[...]
+1 for lsb.parent-forwarding.patch as the implemented behaviour will be
expected from our users anyway.
cu, Lars
Hi!
One thing that never really was resolved were the patches I submitted as a
compromise to some of the early disagreements about late static binding.
I don't think it's a good ideas as it changes the meaning of parent::.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
One thing that never really was resolved were the patches I submitted as
a
compromise to some of the early disagreements about late static binding.I don't think it's a good ideas as it changes the meaning of parent::.
I disagree, the meaning of parent:: is not changed at all relative to php
5.2.*. It behaves exactly the same with the parent forwarding patch. If you
call parent::method() the parent version of the method is still called. It
just provides complete polymorphic calls with static functions which is the
whole purpose for which LSB was even proposed.
Regardless of that, there are two other patches that do the same thing
without altering the behaviour of parent in the current 5.3 code. Though
again, I would think it very unfortunate should we not fix it properly and
just allow parent:: to forward the caller.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
I disagree, the meaning of parent:: is not changed at all relative to
php 5.2.*. It behaves exactly the same with the parent forwarding patch.
I must be misunderstanding the patch then - doesn't it change behavior
of the engine so that parent:: doesn't mean "parent of CLASS"
anymore? If so, could you explain again what it does?
without altering the behaviour of parent in the current 5.3 code. Though
again, I would think it very unfortunate should we not fix it properly
and just allow parent:: to forward the caller.
parent:: is very simple thing - it means "use the name of the parent
class here". I do not thing changing it is a good idea.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
I must be misunderstanding the patch then - doesn't it change behavior
of the engine so that parent:: doesn't mean "parent of CLASS"
anymore? If so, could you explain again what it does?
Of course parent:: still means parent. The change in behavior from the
current patch is just that once you call parent::someMethod you will still
have access to overridden methods in child classes which with the current
patch is not possible. Again, it just provides complete polymorphism for
statics.
parent:: is very simple thing - it means "use the name of the parent
class here". I do not thing changing it is a good idea.
I am of the opinion that parent:: simply means call the parent function
which doesn't change with the patch. I understand that you do not think it
is a good, but I and many other people that have expressed their opinion on
list regarding this matter disagree with you. You seem to be very focused on
the parent:: issue without looking at the whole picture.
Like I said before, I think all of the arguments have been hashed out. I
would just like a yes or no decision that preferably reflects the desire of
the user base. It would be fantastic if some more decision makers had some
time to give their input.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
Of course parent:: still means parent. The change in behavior from the
current patch is just that once you call parent::someMethod you will
still have access to overridden methods in child classes which with the
current patch is not possible. Again, it just provides complete
polymorphism for statics.
OK, looks like I misunderstood what your patch does. Sorry for that.
However, I'm still concerned that foo:: and parent:: would work
differently. IMO, better solution would be to have all :: calls change
called_class, but have also some way to call it without changing
called_class. Something like your forward_static_call, but I'm not sure
not using callbacks is a good idea - all caller function use callbacks
now. Actually, what I'd do would be to generalize forward_static_call
(which I think also needs better name :) and call_user_func into one
function (internally) that has parameter which tells if to update or not
update called_class.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
IMO, better solution would be to have all :: calls change
called_class, but have also some way to call it without changing
called_class. Something like your forward_static_call, but I'm not sure
not using callbacks is a good idea - all caller function use callbacks
now. Actually, what I'd do would be to generalize forward_static_call
(which I think also needs better name :) and call_user_func into one
function (internally) that has parameter which tells if to update or not
update called_class.
I do agree about using a callback with forward_static_call, but one thing
that worries me is that opens the door to really bizzare functionality where
the called_class could wind up being outside of the inheritance chain of the
method being called.
If this could be overcame I think it would be relatively easy to consolidate
this code internally. I will look at it this evening and tomorrow.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi Johannes,
This bug suggests the output buffering re-write in HEAD would be
backported to 5_3: http://bugs.php.net/bug.php?id=42641
Is that still in plan?
I have added it as a "To be discussed" item on http://wiki.php.net/todo/php53.
Regards,
Robin