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 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 callba
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 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:: s
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 s
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
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] http
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
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:
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
t; To: Johannes 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 t
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 enable
On 07.03.2008 02:18, Andi Gutmans wrote:
>> 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 an E_ER
> -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
> -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_com
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 impress
- 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
2008/3/6, Antony Dovgal <[EMAIL PROTECTED]>:
> 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
e
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
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
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 increas
21 matches
Mail list logo