Everything

php

late static binding php6

php.internals

Sebastian Deutsch

19 years ago

hello,

is there a patch for the proposal out there? is anyone working on that
problem?

cheers

sebastian deutsch

Lukas Kahwe Smith

19 years ago

Sebastian Deutsch wrote:

> hello,
>
> is there a patch for the proposal out there? is anyone working on that
> problem?

There might be a patch flying around ...
Last I heard from Marcus was that it seems impossible to find a solution
for this without accepting a slow down/memory footprint increase for
everything else as well. Maybe still worthwhile?

regards,
Lukas

Etienne Kneuss

19 years ago

Lukas Kahwe Smith wrote:

> Sebastian Deutsch wrote:
>> hello,
>>
>> is there a patch for the proposal out there? is anyone working on
>> that problem?
>
> There might be a patch flying around ...
> Last I heard from Marcus was that it seems impossible to find a solution
> for this without accepting a slow down/memory footprint increase for
> everything else as well. Maybe still worthwhile?
>
> regards,
> Lukas
>

My tests on a quite complete patch show no important slowdown, even when
benchmarking
with Zend/bench.php which uses a stupid amount of function calls. About
the memory, it stores
a stack of scopes pointers. Hence it shouldn't consume much under normal
circumstances.

However the patch is not finished, some ambiguities remain. So I won't
publish it for now.
There is another quite old patch out there using a different approach
from mine, you should
be able to google it quite easily.

regards

--
Etienne Kneuss
http://www.colder.ch

Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal

Hodicska Gergely

18 years ago

Hi!


I read this thread, and I would like to ask if is there any decision
about the behavior of inheritance?

I wrote on my blog about late static binding
(http://blog.felho.hu/what-is-new-in-php-53-part-2-late-static-binding.html),
and I came up with the following example:

<?php
class ActiveRecord
{
public static function findByPk($id)
{
$calledClass = get_called_class();
// The magic remains...
}
}

class Blog extends ActiveRecord
{
public static function findByPk($id)
{
// We want to log something.

// Then the parent should do the magic.
parent::findByPk($id);
}
}

Blog::findByPk(1);
?>


In think it would be nice if I could write codes like this. But in the
current snapshot the value of $calledClass is ActiveRecord.


Best Regards,
Felhő

Etienne Kneuss

18 years ago

Hello,

this very subject was already discussed in a thread months ago. Basically,
it's a matter of choice whether fully established calls should break the
resolution or not. Both ways have drawbacks. Implementing both would require
yet another keyword and complications.


On Nov 18, 2007 12:27 PM, Gergely Hodicska <felho@avalon.aut.bme.hu> wrote:

> Hi!
>
>
> I read this thread, and I would like to ask if is there any decision
> about the behavior of inheritance?
>
> I wrote on my blog about late static binding
> (
> http://blog.felho.hu/what-is-new-in-php-53-part-2-late-static-binding.html
> ),
> and I came up with the following example:
>
> <?php
> class ActiveRecord
> {
>     public static function findByPk($id)
>     {
>         $calledClass = get_called_class();
>         // The magic remains...
>     }
> }
>
> class Blog extends ActiveRecord
> {
>     public static function findByPk($id)
>     {
>         // We want to log something.
>
>         // Then the parent should do the magic.
>         parent::findByPk($id);
>     }
> }
>
> Blog::findByPk(1);
> ?>
>
>
> In think it would be nice if I could write codes like this. But in the
> current snapshot the value of $calledClass is ActiveRecord.
>
>
> Best Regards,
> Felhő
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>


-- 
Etienne Kneuss
http://www.colder.ch

Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal

Johannes Schlueter

18 years ago

Hi,

and for me the current behavior feels right: The call to
parrent::findByPk() is an independent call from the call before and
calls an explicit class (the parent one)

johannes

On Sun, 2007-11-18 at 14:21 +0100, "Etienne Kneuss" wrote:

Mike Lively

18 years ago

Johannes Schlüter wrote:

> Hi,
>
> and for me the current behavior feels right: The call to
> parrent::findByPk() is an independent call from the call before and
> calls an explicit class (the parent one)
>
>

This makes no sense to me. It makes it COMPLETELY impossible to do any
form of slightly complicated inheritance and decorators go almost out
the window for statics. It's also slightly inconsistent from how
instance inheritance works.

class A
{
public function test()
{
echo get_class($this)."\n";
}
}

class B extends A
{
public function test()
{
parent::test();
}
}

$a = new A;
$b = new B;

$a->test();
$b->test();

I realize that instance calls are a completely different ball game than
static  calls but LSB was supposed to give us the same flexibility.

I would totally agree that <class name>::<static method>() should break
the caller chain, but in my opinion parent:: should just forward the
called class on. It would allow more complex forms of inheritance,
people that have the kind of OO background that this feature is intended
for I believe will easily understand what's going on. I think more often
than not if someone is going to use parent:: instinctively that they
would be intending the caller to be forwarded (ie: for decorators, also
see polymorphism?). If you REALLY wanted the parent class explicitely
called you can just use the class name.

Basically my point is that I don't believe parent:: should be considered
'fully established' to use Etienne's terminology.

-Mike Lively

Stanislav Malyshev

18 years ago

> I realize that instance calls are a completely different ball game than
> static  calls but LSB was supposed to give us the same flexibility.

Actually, I don't think it was. If you want objects, why not use the
real thing? LSB was created to solve just one particular problem -
inability to distinguish A::method() from B::method() if B extends A.

> called class on. It would allow more complex forms of inheritance,

"more complex" is not always better.

--
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

Hodicska Gergely

18 years ago

> Actually, I don't think it was. If you want objects, why not use the
> real thing?

Just consider that ZF's initial concept was for ActiveRecord a code
which needs LSB.

> "more complex" is not always better.

Did you find my code example "too" complex? I think if LSB is added to
PHP there will be a natural need for this functionality, and a lot of
user will be confused with the result.


Best Regards,
Felhő

Stanislav Malyshev

18 years ago

> PHP there will be a natural need for this functionality, and a lot of
> user will be confused with the result.

What's confusing in reading the manual about what self:: and parent::
mean? Unless by "confusing" you don't mean what all other people mean
but "it works certain way, and I know it well, but since I want it to
work other way I'd pretend I don't understand". That would be really
confusing.

--
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

Hodicska Gergely

18 years ago

> What's confusing in reading the manual about what self:: and parent::
> mean? Unless by "confusing" you don't mean what all other people mean
> but "it works certain way, and I know it well, but since I want it to
> work other way I'd pretend I don't understand". That would be really
> confusing.

You could be ironic (in my view it is not a good argument), but please
check the code which I sent. Or maybe better if you check the last two
examples here:
http://blog.felho.hu/what-is-new-in-php-53-part-2-late-static-binding.html.

I think the *behavior* of the two code blocks is confusing. And I
*understand* that it can be stated in the manual that it works in this
way, but *maybe* not this is the best solution.


Best Regards,
Felhő

Lars Strojny

18 years ago

Hi,


Am Montag, den 19.11.2007, 10:52 +0100 schrieb Hodicska Gergely:
[...]

> I think the *behavior* of the two code blocks is confusing. And I
> *understand* that it can be stated in the manual that it works in this
> way, but *maybe* not this is the best solution.

Why not something like this to fit both needs (I can think on scenarios
for both):

class ActiveRecord {
public static function find($id)
{
echo get_called_class() . "\n";
}
}

class Something extends ActiveRecord {
public static function find($id)
{
return parent::find($id);
}
}

class ActiveRecord2 {
sensitive public static function find($id)
{
echo get_called_class() . "\n";
}
}

class Something2 extends ActiveRecord {
public static function find($id)
{
return parent::find($id);
}
}

class Another extends Something2 {
public static function find($id)
{
return parent::find($id);
}
}

ActiveRecord::find(1);  // "ActiveRecord"
Something::find(2);     // "ActiveRecord"
ActiveRecord2::find(2); // "ActiveRecord2"
Something2::find(1);    // "Something2" => parent method is sensitive
Another::find(1);       // "Something2" => parent method is not sensitive

cu, Lars

--
»Die Glorifizierung der prächtigen underdogs läuft auf
die des prächtigen Systems heraus, das sie dazu macht.«
-- Theodor W. Adorno, »Minima Moralia«: They, the people

Lars Strojny
Nießenstr. 36
51003 Cologne
Jabber/Mail: lars@strojny.net
Weblog: http://usrportage.de

Hodicska Gergely

18 years ago

Hi!

> this very subject was already discussed in a thread months ago.

I have read the thread about it, but I didn't find a conclusion (maybe I
missed it).

> Basically,
> it's a matter of choice whether fully established calls should break the
> resolution or not.

I think the code I sent is an absolutely legitimate use case, and the
current behavior is a little confusing.


Best Regards,
Felhő

Lukas Kahwe Smith

18 years ago

On 18.11.2007, at 12:27, Gergely Hodicska wrote:

> Hi!
>
>
> I read this thread, and I would like to ask if is there any
> decision about the behavior of inheritance?
>
> I wrote on my blog about late static binding (http://blog.felho.hu/
> what-is-new-in-php-53-part-2-late-static-binding.html), and I came
> up with the following example:
>
> <?php
> class ActiveRecord
> {
>     public static function findByPk($id)
>     {
>         $calledClass = get_called_class();
>         // The magic remains...
>     }
> }
>
> class Blog extends ActiveRecord
> {
>     public static function findByPk($id)
>     {
>         // We want to log something.
>
>         // Then the parent should do the magic.
>         parent::findByPk($id);
>     }
> }
>
> Blog::findByPk(1);
> ?>

I think the point of Stas reply was to use self:: instead of parent::.

regards,
Lukas

Alexey Zakhlestin

18 years ago

On 11/19/07, Lukas Kahwe Smith <mls@pooteeweet.org> wrote:

> I think the point of Stas reply was to use self:: instead of parent::.

how would self help? that would mean calling this exact method, not
the method of parent-class

--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/

Lukas Kahwe Smith

18 years ago

On 19.11.2007, at 14:05, Alexey Zakhlestin wrote:

> On 11/19/07, Lukas Kahwe Smith <mls@pooteeweet.org> wrote:
>
>> I think the point of Stas reply was to use self:: instead of
>> parent::.
>
> how would self help? that would mean calling this exact method, not
> the method of parent-class

that way you could add the class name as a second parameter to the
parent method, without having to type it out in every call. Anyways,
I think the current situation is quite clear to me. then again, I
forgot if we also added new magic constants to go along with
__CLASS__ for this (aka __SELF__)?

regards,
Lukas

Alexey Zakhlestin

18 years ago

On 11/19/07, Lukas Kahwe Smith <mls@pooteeweet.org> wrote:

>
> On 19.11.2007, at 14:05, Alexey Zakhlestin wrote:
>
> > On 11/19/07, Lukas Kahwe Smith <mls@pooteeweet.org> wrote:
> >
> >> I think the point of Stas reply was to use self:: instead of
> >> parent::.
> >
> > how would self help? that would mean calling this exact method, not
> > the method of parent-class
>
> that way you could add the class name as a second parameter to the
> parent method, without having to type it out in every call. Anyways,
> I think the current situation is quite clear to me. then again, I
> forgot if we also added new magic constants to go along with
> __CLASS__ for this (aka __SELF__)?

that's possible, but some more "magic" seems to be "natural" here.

As I and several others proposed earlier the best option would be:

parent::method() thinks it is the same class as a caller
ClassName::method() thinks it is ClassName

this would be the least-surprise situation

--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/

Lukas Kahwe Smith

18 years ago

On 19.11.2007, at 14:24, Alexey Zakhlestin wrote:

> On 11/19/07, Lukas Kahwe Smith <mls@pooteeweet.org> wrote:
>>
>> On 19.11.2007, at 14:05, Alexey Zakhlestin wrote:
>>
>>> On 11/19/07, Lukas Kahwe Smith <mls@pooteeweet.org> wrote:
>>>
>>>> I think the point of Stas reply was to use self:: instead of
>>>> parent::.
>>>
>>> how would self help? that would mean calling this exact method, not
>>> the method of parent-class
>>
>> that way you could add the class name as a second parameter to the
>> parent method, without having to type it out in every call. Anyways,
>> I think the current situation is quite clear to me. then again, I
>> forgot if we also added new magic constants to go along with
>> __CLASS__ for this (aka __SELF__)?
>
> that's possible, but some more "magic" seems to be "natural" here.
>
> As I and several others proposed earlier the best option would be:
>
> parent::method() thinks it is the same class as a caller
> ClassName::method() thinks it is ClassName
>
> this would be the least-surprise situation

actually i do not think this is obviously more intuitive than what we
currently have. also that would introduce BC issues. so i think
adding some new magic constants (if they are not yet added) would
probably solve the situation more or less, plus you have self:: if
you need to do something more complex. of course it adds some more
method calls.

regards,
Lukas

Hodicska Gergely

18 years ago

> also that would introduce BC issues.

Can you show a use case for BC?


Current implementation:
<?php
class ActiveRecord
{
public static function findByPk($id)
{
var_dump(get_called_class()); // Blog
var_dump(get_class()); // ActiveRecord
var_dump(__CLASS__); // ActiveRecord
}
}

class Blog extends ActiveRecord {}

Blog::findByPk(1);
?>

The __CLASS__ and the get_class() is the same like in the current PHP
version, and the get_called_class() is not yet introduced. Or do I
overlook something?


Best Regards,
Felhő

Mike Lively

18 years ago

Lukas Kahwe Smith wrote:

>
> On 19.11.2007, at 14:24, Alexey Zakhlestin wrote:
>
>> On 11/19/07, Lukas Kahwe Smith <mls@pooteeweet.org> wrote:
>>>
>>> On 19.11.2007, at 14:05, Alexey Zakhlestin wrote:
>>>
>>>> On 11/19/07, Lukas Kahwe Smith <mls@pooteeweet.org> wrote:
>>>>
>>>>> I think the point of Stas reply was to use self:: instead of
>>>>> parent::.
>>>>
>>>> how would self help? that would mean calling this exact method, not
>>>> the method of parent-class
>>>
>>> that way you could add the class name as a second parameter to the
>>> parent method, without having to type it out in every call. Anyways,
>>> I think the current situation is quite clear to me. then again, I
>>> forgot if we also added new magic constants to go along with
>>> __CLASS__ for this (aka __SELF__)?
>>
>> that's possible, but some more "magic" seems to be "natural" here.
>>
>> As I and several others proposed earlier the best option would be:
>>
>> parent::method() thinks it is the same class as a caller
>> ClassName::method() thinks it is ClassName
>>
>> this would be the least-surprise situation
>
> actually i do not think this is obviously more intuitive than what we
> currently have. also that would introduce BC issues. so i think adding
> some new magic constants (if they are not yet added) would probably
> solve the situation more or less, plus you have self:: if you need to
> do something more complex. of course it adds some more method calls.
>
> regards,
> Lukas
>

There wouldn't be any BC issues, the same methods wind up getting
called, the only thing affected here is the resolution of static:: which
obviously isn't set in stone until 5.3 is out.

Hodicska Gergely

18 years ago

> As I and several others proposed earlier the best option would be:
> parent::method() thinks it is the same class as a caller
> ClassName::method() thinks it is ClassName

Yes, this would be the logical behavior for me too.


Best Regards,
Felhő

Hodicska Gergely

18 years ago

> I think the point of Stas reply was to use self:: instead of parent::.

Hmm, it doesn't make sense to me. (If I am not mistaken calling self
caused segfault.)


Best Regards,
Felhő