# late static binding php6 - Thread: https://externals.io/message/31164 - Original archive: https://news-web.php.net/php.internals/31164 - Started by Sebastian Deutsch on 2007-07-23T03:38:00+00:00 - Messages: 21 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #31164 — Sebastian Deutsch — 2007-07-23T03:38:00+00:00 URL: https://externals.io/message/31164#31164 hello, is there a patch for the proposal out there? is anyone working on that problem? cheers sebastian deutsch --- ## #31176 — Lukas Kahwe Smith — 2007-07-23T09:25:08+00:00 URL: https://externals.io/message/31164#31176 · In reply to: #31164 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 --- ## #31181 — Etienne Kneuss — 2007-07-23T11:13:49+00:00 URL: https://externals.io/message/31164#31181 · In reply to: #31176 Lukas Kahwe Smith wrote: > Sebastian Deutsch wrote: > > […] > > 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 --- ## #33246 — Gergely Hodicska — 2007-11-18T11:27:41+00:00 URL: https://externals.io/message/31164#33246 · In reply to: #31164 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: 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ő --- ## #33249 — Etienne Kneuss — 2007-11-18T13:21:50+00:00 URL: https://externals.io/message/31164#33249 · In reply to: #33246 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: > > 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 --- ## #33251 — johannes@php.net — 2007-11-18T13:35:58+00:00 URL: https://externals.io/message/31164#33251 · In reply to: #33249 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. > > > > > > […] --- ## #33278 — Mike Lively — 2007-11-18T19:44:53+00:00 URL: https://externals.io/message/31164#33278 · In reply to: #33251 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 ::() 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 > > > > […] --- ## #33286 — Stanislav Malyshev — 2007-11-19T06:20:01+00:00 URL: https://externals.io/message/31164#33286 · In reply to: #33278 > 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 --- ## #33293 — Gergely Hodicska — 2007-11-19T08:09:23+00:00 URL: https://externals.io/message/31164#33293 · In reply to: #33286 > 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ő --- ## #33296 — Stanislav Malyshev — 2007-11-19T09:15:47+00:00 URL: https://externals.io/message/31164#33296 · In reply to: #33293 > 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 --- ## #33299 — Hodicska Gergely — 2007-11-19T09:52:15+00:00 URL: https://externals.io/message/31164#33299 · In reply to: #33296 > 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ő --- ## #33304 — Lukas Kahwe Smith — 2007-11-19T12:27:50+00:00 URL: https://externals.io/message/31164#33304 · In reply to: #33246 > 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: > > 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 --- ## #33306 — Alexey Zakhlestin — 2007-11-19T13:05:33+00:00 URL: https://externals.io/message/31164#33306 · In reply to: #33304 > 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/ --- ## #33307 — Lukas Kahwe Smith — 2007-11-19T13:11:40+00:00 URL: https://externals.io/message/31164#33307 · In reply to: #33306 > > > > […] > > 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 --- ## #33310 — Alexey Zakhlestin — 2007-11-19T13:24:28+00:00 URL: https://externals.io/message/31164#33310 · In reply to: #33307 > > > > > […] > > 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/ --- ## #33312 — Lukas Kahwe Smith — 2007-11-19T13:57:11+00:00 URL: https://externals.io/message/31164#33312 · In reply to: #33310 > > > […] > > 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 --- ## #33313 — Hodicska Gergely — 2007-11-19T14:03:20+00:00 URL: https://externals.io/message/31164#33313 · In reply to: #33304 > 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ő --- ## #33348 — Mike Lively — 2007-11-19T18:33:08+00:00 URL: https://externals.io/message/31164#33348 · In reply to: #33312 Lukas Kahwe Smith wrote: > > > > > […] > > 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. --- ## #33331 — Gergely Hodicska — 2007-11-19T20:29:35+00:00 URL: https://externals.io/message/31164#33331 · In reply to: #33310 > 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ő --- ## #33336 — Gergely Hodicska — 2007-11-19T22:06:22+00:00 URL: https://externals.io/message/31164#33336 · In reply to: #33312 > also that would introduce BC issues. Can you show a use case for BC? Current implementation: 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ő --- ## #33431 — Lars Strojny — 2007-11-26T05:43:34+00:00 URL: https://externals.io/message/31164#33431 · In reply to: #33299 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