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
--
PHP Internals - PHP Runtime Development
On Mon, Mar 10, 2008 at 6:41 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
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
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
On Tue, Mar 11, 2008 at 4:31 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
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
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
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
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
[EMAIL PROTECTED]
On Mon, Mar 10, 2008 at 9:49 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
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
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
On Thu, Mar 6, 2008 at 10:10 AM, Johannes Schlüter [EMAIL PROTECTED] 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:
One
i just hope the issue described in
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
Schluter
Cc: PHP Internals List
Subject: Re: [PHP-DEV] 5.3 Release Planning
i just hope the issue described in
http://www.mail-archive.com/internals@lists.php.net/msg32601.h
tml will be resolved before 5.3 is out. it is the only
problem that breaks opcode cacher support as far as i can see
gotcha, i'll check it within 24hours
thanks for your great work
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
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
On 06.03.2008 20:10, Johannes Schlüter 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:
I'd like to ask to re-consider
- 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
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
-Original Message-
From: Antony Dovgal [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 06, 2008 9:36 AM
To: Johannes Schlüter
Cc: PHP Internals List
Subject: Re: [PHP-DEV] 5.3 Release Planning
I'd like to ask to re-consider dropping ze1_compatibility_mode and
finally drop
-Original Message-
From: Cristian Rodriguez [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 06, 2008 10:03 AM
To: php-dev
Subject: Re: [PHP-DEV] 5.3 Release Planning
Also will be nice if zend.enable_gc ini setting is dropped as well
before it is too late , having yet another ini
19 matches
Mail list logo
