hello,
is there a patch for the proposal out there? is anyone working on that
problem?
cheers
sebastian deutsch
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
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
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ő
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.
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
http://www.colder.ch
Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal
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
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.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ő
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
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.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ő
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
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ő
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
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ő
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
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
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/
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
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-classthat 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/
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-classthat 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 ClassNamethis 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
Lukas Kahwe Smith 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-classthat 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 ClassNamethis 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.
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ő
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ő
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ő