So we have at least three different views on concept.
It seems that patch will be delayed again. :(
Thanks. Dmitry.
> -Original Message-
> From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 19, 2007 8:51 PM
> To: Dmitry Stogov
> Cc: 'Marcus Boerger'; 'Lukas K
Do you have any ideas on how to allow this to be at all useful with
inheritance and overriding? If the patch is left to where these examples
would all return 'A' and something wasn't put in place to allow
overloading a static function AND forward on the original called class
What do you mean
Or may be both lines must return "A"? (like Etienne's patches do, and
like
my latest path does)
Yes.
Do you have any ideas on how to allow this to be at all useful with
inheritance and overriding? If the patch is left to where these examples
would all return 'A' and something wasn't put in
On 9/18/07, Pierre Habouzit <[EMAIL PROTECTED]> wrote:
> tag 442250 + wontfix
> thanks
see
http://sourceware.org/bugzilla/show_bug.cgi?id=5043
--
http://www.kissofjudas.net/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I'll be assisting Cipriano Groenendal (CVS account: cipri) with the
PEAR::File_DNS package.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Derick Rethans skrev:
On Wed, 19 Sep 2007, Keryx Web wrote:
3. Will it accept formatting according to date() or strftime() syntax?
date(), but with some additions of course. How, I still need to work
out.
Is that set in stone? Most non-english application developers are
probably more f
So to clarify the question...
I don't understand this. How comes you called A::foo() and you get B?
Doesn't make sense to me. If you call A::foo, you are supposed to get A.
It looks like your intent is that A::foo() returns different things
depending on where it is called, which is not good.
Do you like to make it work for self::foo() and/or static::foo(), but not
for parent::foo() and NAME::foo()?
>From my point of view it is little bit inconsistent, but anyway thank you
for idea.
Dmitry.
> -Original Message-
> From: Alexey Zakhlestin [mailto:[EMAIL PROTECTED]
> Sent: Wedn
Hello Dmitry,
personally I'd argue with the stayed in same hierarchy. So all return B.
macus
Wednesday, September 19, 2007, 12:48:06 PM, you wrote:
> So to clarify the question...
> class A {
> function foo() {
> return get_called_class();
> }
> }
> class B e
On Wed, 19 Sep 2007, Keryx Web wrote:
> Are there any information available about the specifics and progress of
> date_format_locale?
>
> Speaking as a non native English speaker this is a highly anticipated
> function.
>
> Three specific questions:
> 1. Is there an implementation in HEAD?
yes,
Hi all!
Are there any information available about the specifics and progress of
date_format_locale?
Speaking as a non native English speaker this is a highly anticipated
function.
Three specific questions:
1. Is there an implementation in HEAD?
2. Is there any chance of a backport to PHP 5?
So to clarify the question...
Is this the expected behavior? (I would prefer it. My previous patches
worked in this way).
Or may be both lines must return "A"? (like Etienne's patches do, and like
my latest path does)
Thanks. Dmitry.
> -Original Message-
> From: Marcus Boerger [mailto
oh… I guess I see it somehow the third way
class A
{
function foo()
{
return get_called_class();
}
}
class B extends A
{
function bar1()
{
return self::foo(); // it is called using inheritance-rules
}
function bar2()
{
return A::foo(); // it is called di
Hi.
Please commit the attached patch, to cover the integer overflow that
can happen: if ((offset + len) > total_len)
Cheers, Mattias.
On Wed, Sep 19, 2007 at 12:30:53AM -, Stanislav Malyshev wrote:
> stas Wed Sep 19 00:30:53 2007 UTC
>
> Modified files: (Branch: PHP_
Hello Lukas,
right, we already have inheritance all over so we should do it here as
well. Nice work so far.
marcus
Wednesday, September 19, 2007, 9:07:16 AM, you wrote:
> Dmitry Stogov wrote:
>> I am not sure which behavior shouldbe in final patch.
>> It seems like support for inheritance
Dmitry Stogov wrote:
I am not sure which behavior shouldbe in final patch.
It seems like support for inheritance provides more flixebility, but makes
concept harder to understand.
Well inheritance is an advanced OO concept. As such its something that
requires a bit of getting into. But making
16 matches
Mail list logo
