als@lists.php.net
> Cc: Stanislav Malyshev; Baptiste Autin; Zoe Slattery; Dmitry
> Stogov; Marcus Boerger; Lukas Kahwe Smith; Michael Lively;
> Etienne Kneuss; Andi Gutmans
> Subject: Re: [PHP-DEV] [patch] Late static bindings (LSB)
>
>
> Sorry to persist with this, but I
Sorry to persist with this, but I think it could be really useful to
clarify the meaning of static:: outside of method bodies...
particularly since parent:: and self:: can already behave very
strangely in such scenarios (see
http://news.php.net/php.internals/32443 ).
For example, I find the follow
Hello,
static methods seem exactly like dynamic binded methods now, is there
any chance that "abstract static function" being restored from E_STRICT
limitation? Currently it is allowed in interfaces, but forbidden in abstract
class, I don't know why php implements "static method" in this way, t
So, if I understand you well, Stanislas, you are personally not much into
"static::" but more into making that sort of code working :
interface iC {
public $structure;
}
abstract class A implements iC {
public function display() {
echo self::$structure;
}
}
Gutmans
Subject: Re: [PHP-DEV] [patch] Late static bindings (LSB)
Hello,
if I understand you correctly, you want to radically change the behavior of
self:: ?
This is not doable as it would break tons of scripts!
Regards
On 9/27/07, Baptiste Autin <[EMAIL PROTECTED]> wrote:
>
> >P
Hello,
if I understand you correctly, you want to radically change the behavior of
self:: ?
This is not doable as it would break tons of scripts!
Regards
On 9/27/07, Baptiste Autin <[EMAIL PROTECTED]> wrote:
>
> >People generally prefer compile-time
> >control which is derived from definition r
>People generally prefer compile-time
>control which is derived from definition rather than per-instance
>runtime control (implementing interface vs. checking each time if class
>has certain methods).
It's me again, sorry.
So, if I understand you well, Stanislas, you are personally not much int
On 20/09/2007, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
>
> I think we better spend time on figuring out the concept and then do the
> patch than first do the patch and then discover we don't know how it was
> supposed to work :)
Here's a question that I think hasn't been discussed and isn't
On 9/24/07, Michael Lively <[EMAIL PROTECTED]> wrote:
> The very phrase late static binding is an oxymoron of sorts :)
that's because the term we use is not correct… :)
it would be better to say "late binding of static methods"
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
27;Marcus Boerger'" <[EMAIL PROTECTED]>; "'Lukas Kahwe Smith'"
<[EMAIL PROTECTED]>; "'Michael Lively'" <[EMAIL PROTECTED]>; "'Etienne
Kneuss'" <[EMAIL PROTECTED]>; ; "'Andi Gutmans'"
Couldn't I write: isset(static::$structure) ?
You could, but that's only runtime. People generally prefer compile-time
control which is derived from definition rather than per-instance
runtime control (implementing interface vs. checking each time if class
has certain methods).
So this wil
>If you mean Client's $structure, the you have to use static::$structure
>and it should work. However it's quite a bad design here since you have
>no way to ensure class inheriting from Entity would have $structure.
Couldn't I write: isset(static::$structure) ?
BTW, sorry for my recent vulgar
Like that one, ridiculous:
static private function getStruct(&$class) {
if(!(is_array(Entity::$struct) && array_key_exists($class,
Entity::$struct))) {
eval("if(!isset(".$class."::\$structure))
self::array2xml('".$class."');");
eval("Entity::\$struct[\$class] = new SimpleX
>It's becoming messy now - we now need to start to invent all kinds of
>complex propagation rules for it in parallel with the true object
>propagation rules. Why not just have an object then?
Because if you could only see the incredible number of "get_class($this)"
and of "if(__CLASS__!=get_class(
With static:: you are not able to call method of parent with the same name.
Ah, I see you point. I'm starting to dislike all this idea of "let's
have an object without really having an object"... It's becoming messy
now - we now need to start to invent all kinds of complex propagation
rules f
I mean, when you want to go upwards, to reach an ancestor class.
You can't go upwards, because there's no upwards for classes. You can
use the information you already have, via static:: and function that is
analogous to it for static and get_parent_class for non-static.
But it could also me
>__CLASS__ returns name of the class, get_parent_class() is the name of
>parent class, those are entirely different things, nothing to do with
>compiler/run time. Class always has one name and one parent or none.
Sorry, I meant:
__CLASS__
and
get_class($this)
They are both different things, and
it may be a good compromise.
> Thanks. Dmitry.
>> -Original Message-
>> From: Stefan Walk [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, September 20, 2007 1:10 PM
>> To: Dmitry Stogov; internals@lists.php.net
>> Subject: Re: [PHP-DEV] [patch] Late static b
#x27;; 'Lukas Kahwe Smith';
> 'Etienne Kneuss'; internals@lists.php.net; 'Andi Gutmans'
> Subject: Re: [PHP-DEV] [patch] Late static bindings (LSB)
>
>
> > class TableSelectExplainBuilder extends TableSelectBuilder
> > {
> >stat
Now, let's say the "base" class is called "Entity".
And let's say I have an inherited class called "Client":
Abstract Class Entity {
function read()
{}
function delete()
{}
...
}
Class Client extends Entity
{
public $id;
public $first_name;
class TableSelectExplainBuilder extends TableSelectBuilder
{
static protected function buildSelectQuery()
{
return "EXPLAIN ".parent::buildSelectQuery();
}
}
Why not do static:: instead of parent:: here?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://w
Stogov; 'Marcus Boerger'; 'Lukas Kahwe Smith';
> 'Michael Lively'; 'Etienne Kneuss'; internals@lists.php.net;
> 'Andi Gutmans'
> Subject: Re: [PHP-DEV] [patch] Late static bindings (LSB)
>
>
> Stanislav Malyshev wrote:
> >
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
internals@lists.php.net
Subject: Re: [PHP-DEV] [patch] Late static bindings (LSB)
Is it possible or feasible to distinguish betwenn parent::
and NameOfParentClass::? That would allow to push a call "up"
while preserving the called name while not making Class::
mean different things depending on
ibe, visit: http://www.php.net/unsub.php
-Original Message-
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
Sent: jeudi 20 septembre 2007 20:58
To: Zoe Slattery
Cc: Dmitry Stogov; 'Marcus Boerger'; 'Lukas Kahwe Smith'; 'Michael Lively';
'Etienne Kneuss&#x
How about writing the test cases first - and then the patch?
I'm fine with that - that's why I asking people for examples of what
they want to do with it.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Inte
Stanislav Malyshev wrote:
So we have at least three different views on concept.
It seems that patch will be delayed again. :(
I think we better spend time on figuring out the concept and then do
the patch than first do the patch and then discover we don't know how
it was supposed to work :)
Is it possible or feasible to distinguish betwenn parent:: and
NameOfParentClass::? That would allow to push a call "up" while
I'm not sure I understand - what's the difference? Can you give an example?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408
So we have at least three different views on concept.
It seems that patch will be delayed again. :(
I think we better spend time on figuring out the concept and then do the
patch than first do the patch and then discover we don't know how it was
supposed to work :)
--
Stanislav Malyshev, Zend
Is it possible or feasible to distinguish betwenn parent:: and
NameOfParentClass::? That would allow to push a call "up" while
preserving the called name while not making Class:: mean different
things depending on the location of the call, which is a very bad thing
IMO (it's an effect that may not
2007 1:10 PM
> To: Dmitry Stogov; internals@lists.php.net
> Subject: Re: [PHP-DEV] [patch] Late static bindings (LSB)
>
>
> Is it possible or feasible to distinguish betwenn parent::
> and NameOfParentClass::? That would allow to push a call "up"
> while preser
cus Boerger'; 'Lukas Kahwe Smith'; 'Michael Lively';
> 'Etienne Kneuss'; internals@lists.php.net; 'Andi Gutmans'
> Subject: Re: [PHP-DEV] [patch] Late static bindings (LSB)
>
>
> > So to clarify the question...
>
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
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.
]
> Sent: Wednesday, September 19, 2007 3:26 PM
> To: Dmitry Stogov
> Cc: Marcus Boerger; Lukas Kahwe Smith; Michael Lively;
> Etienne Kneuss; internals@lists.php.net; Stanislav Malyshev;
> Andi Gutmans
> Subject: Re: [PHP-DEV] [patch] Late static bindings (LSB)
>
>
> oh
return "A"? (like Etienne's patches do, and like
> my latest path does)
> Thanks. Dmitry.
>> -Original Message-
>> From: Marcus Boerger [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, September 19, 2007 12:43 PM
>> To: Lukas Kahwe Smith
>>
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 19, 2007 12:43 PM
> To: Lukas Kahwe Smith
> Cc: Dmitry Stogov; 'Michael Lively'; 'Etienne Kneuss';
> internals@lists.php.net; 'Stanislav Malyshev'; 'Andi Gutmans'
> S
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
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
ndi Gutmans
> Subject: Re: [PHP-DEV] [patch] Late static bindings (LSB)
>
>
> There is a serious problem with both of these patches as they are now.
>
> I understand the principal behind
>
> class A {
> static public function test() { echo get_called_class
EMAIL PROTECTED]>
Cc: ; "Stanislav Malyshev" <[EMAIL PROTECTED]>; "Andi
Gutmans" <[EMAIL PROTECTED]>
Sent: Tuesday, September 18, 2007 5:59 AM
Subject: RE: [PHP-DEV] [patch] Late static bindings (LSB)
Hi Etienne,
At first thank you for catching the issue.
I deside n
Since the call A::foo() is completely defined and that no "fall back"
occurs, I guess "A" is more expected as a result of this script.
Your patch will return B. I discussed this matter quite heavily on
#php.pecl and the expectations were also that "A" should get returned here.
I think you are ri
Michael Lively wrote:
Since the call A::foo() is completely defined and that no "fall back"
occurs, I guess "A" is more expected as a result of this script.
Your patch will return B. I discussed this matter quite heavily on
#php.pecl and the expectations were also that "A" should get returned
he
- Original Message -
From: "Etienne Kneuss" <[EMAIL PROTECTED]>
To:
Sent: Sunday, September 16, 2007 10:50 AM
Subject: Re: [PHP-DEV] [patch] Late static bindings (LSB)
However this causes a seg fault in your current patch. I will do a little
more checking to
Since the call A::foo() is completely defined and that no "fall back"
occurs, I guess "A" is more expected as a result of this script.
Your patch will return B. I discussed this matter quite heavily on
#php.pecl and the expectations were also that "A" should get returned
here.
I've taken a look
Hello,
I made the update anyway as it looked like it wouldn't take much time.
Attached is a updated version of my patch, along with all the tests
related to it:
http://patches.colder.ch/Zend/late_static_bindings_take7.patch?markup
--
Etienne Kneuss
http://www.colder.ch
Men never do evil so c
Hi Dmitry,
your patch fails with one test of mine. It may show a difference in the
conception we have of LSB's usage, consider the following snip:
--%<-
http://www.colder.ch
Men never do evil so completely and cheerfully as
when they do it from a religiou
Attached.
Thanks. Dmitry.
> -Original Message-
> From: Etienne Kneuss [mailto:[EMAIL PROTECTED]
> Sent: Sunday, September 09, 2007 11:02 PM
> To: Dmitry Stogov
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [patch] Late static bindings (LSB)
>
>
>
Thanks. Dmitry.
-Original Message-
From: Etienne Kneuss [mailto:[EMAIL PROTECTED]
Sent: Friday, August 24, 2007 5:19 PM
To: internals@lists.php.net
Subject: [PHP-DEV] [patch] Late static bindings (LSB)
Hi internals,
here is a patch that implements Late static bindinds in a way that
m
nks. Dmitry.
> -Original Message-
> From: Etienne Kneuss [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 24, 2007 5:19 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] [patch] Late static bindings (LSB)
>
>
> Hi internals,
>
> here is a patch that impleme
Hi internals,
here is a patch that implements Late static bindinds in a way that
minimizes the performance hits that were feared.
There is no significant slowdown or memory usage increase when running
Zend/bench.php, which I assume is a
good enough bench for that kind of matter, as it involves
53 matches
Mail list logo
