Hi Johannes,
> thanks for the patch, next to platform specific stuff I'm wondering
> whether the shutdown order is right:
> [..snip..]
> Destructors can be PHP code, as can some ob callback so I think the order
> should be changed.
Yes, great catch, the order is incorrect. We use a different orde
Just a quick reminder at Johannes and I were looking for feedback by
July 9th (aka tomorrow) ..
On 02.07.2008, at 22:00, Lukas Kahwe Smith wrote:
Summary:
Everybody review [1] and make sure all items you care about are on
the list and your name only appears next to stuff you are actually
Hi!
With current proposal we can call the same static method from the same
context with different behavior parent::foo(), self::foo(), A::foo().
That's exactly what I said when I explained why I didn't like the idea
of chainging parent::. I was told I am the only one that doesn't like
parent
Hi!
Each call to static method of parent class (it doesn't mater if it was
done using parent:: or something else) assumes forwarding of called context.
That would make it impossible to do non-forwarding call. Which means you
can't use something like ActiveRecord pattern (which uses LSB) insid
Hi!
Well... we had some discussions on the i18n list, and everyone except
Stas said we should have consistent class prefixes.
"Everyone" being you and one other person, and "except" being all people
actually working on the extension.
Anyway, I don't want to start another round of bikesheddi
Hi Nuno, all,
I didn't test it, but yeah that should fix the # problem. :-) BTW, I also
had other ideas about checking for , etc. tags in the inline
HTML scanning part, so the largest chunk of HTML is always grabbed (I'll
send the patch in the future; didn't modify anything yet, and it's not
rela
On Tue, 8 Jul 2008, Joe Orton wrote:
> The result of calling getTimezone() on a Date object results in a
> DateTimeZone object with a reference to the dateobj->time->tz_info
> object which may get later destroyed.
>
> This can cause unexpected script behaviour or interpreter crashes, test
> ca
The result of calling getTimezone() on a Date object results in a
DateTimeZone object with a reference to the dateobj->time->tz_info
object which may get later destroyed.
This can cause unexpected script behaviour or interpreter crashes, test
case in attachment (1).
When I fixed this the obvio
Hi,
I wouldn't mind if we weighted the pros/cons of the current solution
against the initial proposition now that we had nearly 1 year to
experience with the way it is now.
I really feel that the current way is something that we will regret
later. And as of which solution to adopt, either always-
Just a quick note to whomever did the mail server configuration:
After a [enhancement pill name here] SPAM message "from" me (not
really, but you know what I mean) hit the Internals list and bounced
back, I saw the 550.
"550: we're manly enough already"
Nice. That made my mornin
Am 02.07.2008 um 22:00 schrieb Lukas Kahwe Smith:
1) intl extension
Last discussion ended without a decision on the class naming [10]. I
specifically remember Derick taking issue with intl ext "invading"
the date ext namespace. Stas however arguing that the intl ext is
supposed to bring so
Am 02.07.2008 um 22:00 schrieb Lukas Kahwe Smith:
1) intl extension
Last discussion ended without a decision on the class naming [10]. I
specifically remember Derick taking issue with intl ext "invading"
the date ext namespace. Stas however arguing that the intl ext is
supposed to bring so
Hi Mike,
Yes. It was the initial proposal that was quite consistent.
With current proposal we can call the same static method from the same
context with different behavior parent::foo(), self::foo(), A::foo().
I didn't get why can I call parent's method, but cannot call "self" or
grand-parent's
Hi,
I have seen a "NEEDS DEVELOPER" flag on the TODO for the "Implement
RecursiveTreeIterator in C" task, so I would like to propose my
implementation [1].
Currently it follows the PHP implementation, except that it does not have a
$prefix public property (how about a private property and a se
-- Forwarded message --
From: Mike Lively <[EMAIL PROTECTED]>
Date: Tue, Jul 8, 2008 at 6:23 AM
Subject: Re: [PHP-DEV] Re: parent:: forwarding
To: Dmitry Stogov <[EMAIL PROTECTED]>
On Tue, Jul 8, 2008 at 4:39 AM, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
> Each call to static me
"Class names" are already context-dependent.
test();
?>
Thanks. Dmitry.
Alexey Zakhlestin wrote:
> On Tue, Jul 8, 2008 at 3:39 PM, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
>> I took a look into the patch and I don't like it all.
>>
>> At first, I don't see any consistency there.
>> Why parent::
Hi Lucas,
> I am proposing the following RFC to improve signal handling in the Zend
> Engine:
thanks for the patch, next to platform specific stuff I'm wondering
whether the shutdown order is right:
- /* 2. Call all possible __destruct() functions */
+ /* 2. Reset max_execution_time
On Tue, Jul 8, 2008 at 3:39 PM, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
> I took a look into the patch and I don't like it all.
>
> At first, I don't see any consistency there.
> Why parent:: does forwarding but self::, static:: and "class names" don't?
"class names" don't because, people expect
5.2 didn't have static:: so it cannot be a BC break.
Thanks. Dmitry.
Derick Rethans wrote:
> On Tue, 8 Jul 2008, Dmitry Stogov wrote:
>
>> I took a look into the patch and I don't like it all.
>>
>> At first, I don't see any consistency there.
>> Why parent:: does forwarding but self::, static::
On Tue, 8 Jul 2008, Dmitry Stogov wrote:
> I took a look into the patch and I don't like it all.
>
> At first, I don't see any consistency there.
> Why parent:: does forwarding but self::, static:: and "class names" don't?
>
> At second, it's too complicated.
>
> I would propose more consistent
Hi Etienne,
I took a look into the patch and I don't like it all.
At first, I don't see any consistency there.
Why parent:: does forwarding but self::, static:: and "class names" don't?
At second, it's too complicated.
I would propose more consistent (from my point of view) and simpler patch.
Don't you guys have bigger fish to fry?
--
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
22 matches
Mail list logo
