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
Hi,
Thanks for working on this. However I don't think more effort should be
wasted with this script. It's a bogus approach to the problem and it will
always generate many false-positives (disclaimer: I'm the author of the
original script and it was like a POC).
Thus my idea is to move along to
i want to make changes to a pear module to support iCalendars
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
distributing a new package
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 11.03.2008 13:17, Scott McNaught [Synergy 8] wrote:
> Hey guys,
>
> I don’t know whether to post this as a bug or not. But I was tricked when
> programming today.
>
> It seems that the character "*" is non-strictly equivalent to 0.
> Is this the correct behavior or am I missing something?
"If you compare an integer with a string, the string is converted to a
number. If you compare two numerical strings, they are compared as
integers." Well... I just feel stupid now :)
I am writing something which is extracting parts of a crontab. The variable
contained "*" was being compared to 0.
On Tue, Mar 11, 2008 at 11:17 AM, Scott McNaught [Synergy 8]
<[EMAIL PROTECTED]> wrote:
> Hey guys,
>
> I don't know whether to post this as a bug or not. But I was tricked when
> programming today.
>
> It seems that the character "*" is non-strictly equivalent to 0. Is this
> the correct beh
On 3/11/08, Scott McNaught [Synergy 8] <[EMAIL PROTECTED]> wrote:
> I don't know whether to post this as a bug or not. But I was tricked when
> programming today.
>
> It seems that the character "*" is non-strictly equivalent to 0. Is this
> the correct behavior or am I missing something?
>
>
Hey guys,
I don’t know whether to post this as a bug or not. But I was tricked when
programming today.
It seems that the character "*" is non-strictly equivalent to 0. Is this the
correct behavior or am I missing something?
Test case:
Shows boolean(true).
I was unable to find any documen
When php_stream_cast is passed any of the _AS_FD-like options, what is
the ret argument supposed to point to? This does not seem to be decided
consistently; from a quick survey:
ext/openssl/xp_ssl.c:
php_openssl_sockop_cast() presumes that *ret has sizeof(void *)
ext/soap/php_http.c:
st
On 11.03.2008 08:00, Alexandr Savchuk wrote:
> 3. There are really many problem reports about "not optional var is
> initialized"
> Also in most part of these cases not optional var is inialized by null
> value. Why is this requrement ? And why ?
I believe this notice should be disabled, as it's
Hi Marcus,
I've just rechecked the "-e" option, and it works fine for me.
I'm wonderwed why (and how) it didn't work for you.
I hope I already answered your questions and you see the needness of
this patch.
So I hope you agree that I'll commit it tomorrow (with comments about
compiler options)
T
14 matches
Mail list logo
