# __getStatic - Thread: https://externals.io/message/39969 - Original archive: https://news-web.php.net/php.internals/39969 - Started by Timm Friebe on 2008-08-14T22:38:06+00:00 - Messages: 26 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/39969.md?page=2 - 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 --- ## #39969 — Timm Friebe — 2008-08-14T22:38:06+00:00 URL: https://externals.io/message/39969#39969 Hi, on the member side, there is __get, __set, __isset and __unset - on the method side, there is __call (and now: __callstatic). I was wondering why there was no __getstatic and friends, but failed to find a reason. Attached you'll find an incomplete patch against PHP_5_3 to add this functionality. If you like it let me know and I can finish it. - Timm --- ## #39970 — Timm Friebe — 2008-08-14T22:44:19+00:00 URL: https://externals.io/message/39969#39970 · In reply to: #39969 Hi again, > Attached you'll find an incomplete patch against PHP_5_3 to add this > functionality. If you like it let me know and I can finish it. Darn, seems the list didn't like my text/plain attachment. Well, here we go: http://sitten-polizei.de/php/get-static.diff - Timm --- ## #39972 — Nathan Nobbe — 2008-08-14T23:49:35+00:00 URL: https://externals.io/message/39969#39972 · In reply to: #39970 > Hi again, > > Attached you'll find an incomplete patch against PHP_5_3 to add this > > […] > > Darn, seems the list didn't like my text/plain attachment. Well, here we > go: > > http://sitten-polizei.de/php/get-static.diff i think this is a great idea and a natural candidate for addition. -nathan --- ## #39973 — Ryan Panning — 2008-08-15T03:45:20+00:00 URL: https://externals.io/message/39969#39973 · In reply to: #39972 Nathan Nobbe wrote: > > > > […] > > > i think this is a great idea and a natural candidate for addition. > > -nathan > I would also like to see this in 5.3. Unfortunately this feature is apart of a RFC that did not make it in 5.3. It is goofy that __callStatic() got in without the other __*Static()'s. I think it made it in before this RFC was created. http://wiki.php.net/rfc/static-classes#class_model_rules It would be great if all the __*Static()'s could make it in 5.3 but I highly doubt that it will. --- ## #39977 — Marcus Boerger — 2008-08-15T10:06:57+00:00 URL: https://externals.io/message/39969#39977 · In reply to: #39970 Hello Timm, Friday, August 15, 2008, 12:44:19 AM, you wrote: > Hi again, > > […] > Darn, seems the list didn't like my text/plain attachment. Well, here we go: > http://sitten-polizei.de/php/get-static.diff Patch looks pretty good. Plaease add __issetStatic and __unsetStatic. Then provide tests and submit to HEAD. For 5.3 Lukas and Johannes have to agree but I am sure they first want to see it in HEAD. Best regards, Marcus --- ## #40017 — Lukas Kahwe Smith — 2008-08-20T16:39:26+00:00 URL: https://externals.io/message/39969#40017 · In reply to: #39977 > Hello Timm, > > Friday, August 15, 2008, 12:44:19 AM, you wrote: > > > […] > > > […] > > > […] > > > […] > > Patch looks pretty good. Plaease add __issetStatic and > __unsetStatic. Then > provide tests and submit to HEAD. For 5.3 Lukas and Johannes have to > agree > but I am sure they first want to see it in HEAD. Hope we havent missed any other we need to make this stuff complete .. But here is the blessing of the two RM's to have this committed before the alpha2 release .. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #40065 — George Antoniadis — 2008-08-22T12:08:42+00:00 URL: https://externals.io/message/39969#40065 · In reply to: #40017 I thought this had allready been denied, or am I wrong? Also can new features still be implemented for 5.3? Isn't that closed? Don't get me wrong, I SO want this feature! :P G. On Wed, Aug 20, 2008 at 7:39 PM, Lukas Kahwe Smith wrote: > > > > Hello Timm, > > […] > > > Hope we havent missed any other we need to make this stuff complete .. > But here is the blessing of the two RM's to have this committed before the > alpha2 release .. > > regards, > Lukas Kahwe Smith > mls@pooteeweet.org --- ## #40066 — david.zuelke@bitextender.com — 2008-08-22T13:06:22+00:00 URL: https://externals.io/message/39969#40066 · In reply to: #40065 Am 22.08.2008 um 14:08 schrieb George Antoniadis: > I thought this had allready been denied, or am I wrong? > Also can new features still be implemented for 5.3? Isn't that closed? > > Don't get me wrong, I SO want this feature! :P The mail below explicitly states that both release managers have given their okay for implementing any missing __magicStatic() methods... read the mail again! - David P.S: top posting is evil > > > G. > > On Wed, Aug 20, 2008 at 7:39 PM, Lukas Kahwe Smith > wrote: > > > […] --- ## #40067 — Hannes Magnusson — 2008-08-22T18:32:42+00:00 URL: https://externals.io/message/39969#40067 · In reply to: #40066 > Am 22.08.2008 um 14:08 schrieb George Antoniadis: > > > […] > > The mail below explicitly states that both release managers have given their > okay for implementing any missing __magicStatic() methods... read the mail > again! Well... I actually thought this was rejected too until Marcus came out of the blue and then Lukas giving the RMs blessing.. I can't find a single usecase for this, and see absolutely no point with it and hardly consider this "making this [__call/__get/__isset magic] complete". However, I could not care less of it gets in or not. -Hannes --- ## #40069 — George Antoniadis — 2008-08-22T22:28:07+00:00 URL: https://externals.io/message/39969#40069 · In reply to: #40067 I am pretty sure that it's most common (and weirdest) use will be to have some kind of custom superglobals that will piss a lot of people off. Easier registry patterns etc. registry::$name = 'test'; echo registry::$name; Sounds stupid but since custom superglobals have been denied it's the next best thing ;) G. On Fri, Aug 22, 2008 at 9:32 PM, Hannes Magnusson < hannes.magnusson@gmail.com> wrote: > On Fri, Aug 22, 2008 at 15:06, David Zülke > wrote: > > […] > their > > […] > mail > > […] > > Well... I actually thought this was rejected too until Marcus came out > of the blue and then Lukas giving the RMs blessing.. > > I can't find a single usecase for this, and see absolutely no point > with it and hardly consider this "making this [__call/__get/__isset > magic] complete". However, I could not care less of it gets in or not. > > -Hannes --- ## #40323 — Timm Friebe — 2008-09-08T09:23:09+00:00 URL: https://externals.io/message/39969#40323 · In reply to: #40017 Hi, [...__(set|get|unset|isset)static()...] > > […] > > Hope we havent missed any other we need to make this stuff complete .. > But here is the blessing of the two RM's to have this committed before > the alpha2 release .. I've updated the patch and added some tests with it. http://sitten-polizei.de/php/getstatic.diff This requires a zend_vm_gen.php as I needed a new opcode (ZEND_ASSIGN_CLASS, 137). Please review this patch carefully, especially the part in zend_vm_def.h, I'm not sure this is correct. - Timm --- ## #40815 — Lukas Kahwe Smith — 2008-10-01T07:52:36+00:00 URL: https://externals.io/message/39969#40815 · In reply to: #40323 > Hi, > > [...__(set|get|unset|isset)static()...] > > […] > > I've updated the patch and added some tests with it. > > http://sitten-polizei.de/php/getstatic.diff > > This requires a zend_vm_gen.php as I needed a new opcode > (ZEND_ASSIGN_CLASS, 137). Please review this patch carefully, > especially the part in zend_vm_def.h, I'm not sure this is correct. Can someone review this patch? regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #40933 — Stanislav Malyshev — 2008-10-10T20:58:16+00:00 URL: https://externals.io/message/39969#40933 · In reply to: #40815 Hi! > > […] Looked at the patch. There's some things I noticed there: 1. _getstatic->common.fn_flags |= ~ZEND_ACC_ALLOW_STATIC; What was the idea here? Maybe ~ is not intended? 2. Do we really need ZEND_ASSIGN_CLASS opcode, can't we reuse ASSIGN_OBJ with flag, as we do for fetches? 3. In zend_std_set_static_property, I'm not sure we need to do zend_update_class_constants there. We won't be using any values from it. 4. In zend_std_set_static_property, why you create new property_info two times when property does not exist? 5. In zend_std_set_static_property, old value of the property is not destroyed. Also, I'm not sure separation is handled there correctly - previous value may be shared between variables, and just replacing it would affect all shared variables. You may see how property handler does assignments. Alternatively, in the absence of the setter, you may just use the existing assignment handler, just fetching the zval** as before and passing it to zend_assign_to_variable. This would probably be better - less stuff to do. 6. What would happen with foo::$bar += 1? I don't see assign-ops handled anywhere in the patch. 7. Does zend_std_get_static_property handle the case of return by-ref like property one does? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #41159 — Lukas Kahwe Smith — 2008-10-16T18:07:01+00:00 URL: https://externals.io/message/39969#41159 · In reply to: #40933 > Hi! > > > […] > > Looked at the patch. There's some things I noticed there: > 1. _getstatic->common.fn_flags |= ~ZEND_ACC_ALLOW_STATIC; > What was the idea here? Maybe ~ is not intended? > > 2. Do we really need ZEND_ASSIGN_CLASS opcode, can't we reuse > ASSIGN_OBJ with flag, as we do for fetches? > > 3. In zend_std_set_static_property, I'm not sure we need to do > zend_update_class_constants there. We won't be using any values from > it. > > 4. In zend_std_set_static_property, why you create new property_info > two times when property does not exist? > > 5. In zend_std_set_static_property, old value of the property is not > destroyed. Also, I'm not sure separation is handled there correctly > - previous value may be shared between variables, and just replacing > it would affect all shared variables. You may see how property > handler does assignments. > Alternatively, in the absence of the setter, you may just use the > existing assignment handler, just fetching the zval** as before and > passing it to zend_assign_to_variable. This would probably be better > - less stuff to do. > > 6. What would happen with foo::$bar += 1? I don't see assign-ops > handled anywhere in the patch. > > 7. Does zend_std_get_static_property handle the case of return by- > ref like property one does? > hmm .. i also emailed Timm a few weeks ago and got no reaction. the question now is .. does someone else care enough to work through the issues Stas has noted to get things in shape to be committed? regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #41164 — Stanislav Malyshev — 2008-10-16T18:41:10+00:00 URL: https://externals.io/message/39969#41164 · In reply to: #41159 Hi! > hmm .. i also emailed Timm a few weeks ago and got no reaction. the > question now is .. does someone else care enough to work through the > issues Stas has noted to get things in shape to be committed? Well, this thing is trickier that it appears initially. It can be done, of course, but it requires serious attention to the details (e.g. cases like +=, doing refcounts/separation correctly on assignment, etc.). This patch is definitely not ready, so I'd wait with it unless we get really good one very-very soon. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #41277 — Timm Friebe — 2008-10-19T13:01:31+00:00 URL: https://externals.io/message/39969#41277 · In reply to: #41159 Hi, First of all, thanks for reviewing and the feedback. I knew this wasn't perfect, and tried to understand what was previously done for __get and __set and transport that to the static counterparts. Unfortunately not all "infrastructure" like the std_*_property_handler callbacks is in place for static properties so this had to be created, too. Lukas writes: > hmm .. i also emailed Timm a few weeks ago and got no reaction. the > question now is .. does someone else care enough to work through the > issues Stas has noted to get things in shape to be committed? I've been quite busy with personell and budget planning at our company and have thus had neither time yet to shift through my private e-mail nor to do any programming, be it for private projects or for PHP. I was hoping someone else might pick up on this patch and try to complete it, it's been asked for a couple of times in different forums / newsgroups / this list (a Google search reveals these). On the other hand, there's only one really good use-case that pops to my mind for __getStatic(), and maybe the "type-safe object properties" pattern Sebastian (Bergmann) had in his blog may be another one, but nothing people would care enough for (especially once compared to the feelings around namespaces), so that's probably why this hasn't happened!:-) Stas writes: > This patch is definitely not ready, so I'd wait with it unless we get > really good one very-very soon. I guess very-very soon is already over, and yes, absolutely, this patch is far from perfection, so I'd also delay it. Maybe someone (Lars from http://wiki.php.net/rfc/static-classes?) might also want to gather some motivation for the __*Static() methods as in good use cases... - Timm --- ## #42430 — George Antoniadis — 2009-01-01T00:36:42+00:00 URL: https://externals.io/message/39969#42430 · In reply to: #41277 > Hi, > First of all, thanks for reviewing and the feedback. I knew this wasn't > perfect, and tried to understand what was previously done for __get and > __set and transport that to the static counterparts. Unfortunately not all > "infrastructure" like the std_*_property_handler callbacks is in place for > static properties so this had to be created, too. > > Lukas writes: > > > […] > > I've been quite busy with personell and budget planning at our company and > have thus had neither time yet to shift through my private e-mail nor to do > any programming, be it for private projects or for PHP. I was hoping someone > else might pick up on this patch and try to complete it, it's been asked for > a couple of times in different forums / newsgroups / this list (a Google > search reveals these). On the other hand, there's only one really good > use-case that pops to my mind for __getStatic(), and maybe the "type-safe > object properties" pattern Sebastian (Bergmann) had in his blog may be > another one, but nothing people would care enough for (especially once > compared to the feelings around namespaces), so that's probably why this > hasn't happened!:-) > > Stas writes: > > > […] > > I guess very-very soon is already over, and yes, absolutely, this patch is > far from perfection, so I'd also delay it. Maybe someone (Lars from > http://wiki.php.net/rfc/static-classes?) might also want to gather some > motivation for the __*Static() methods as in good use cases... > > - Timm > Any news on this? :) I don't see this in 5.3 but are there any hopes for pushing this on the HEAD of 6 sometime soon? :) --- ## #42431 — Lukas Kahwe Smith — 2009-01-01T02:53:02+00:00 URL: https://externals.io/message/39969#42431 · In reply to: #42430 > > […] > > Any news on this? :) > I don't see this in 5.3 but are there any hopes for pushing this on > the HEAD > of 6 sometime soon? :) Stas reviewed the patch and determined that it needs a bit more work. Its too late for 5.3 I would say now, but the main stumbling point is the lack of a proper patch. Its still noted on the "future PHP releases" 5.3 todo wiki page. regards, Lukas --- ## #42432 — Lars Strojny — 2009-01-01T11:12:37+00:00 URL: https://externals.io/message/39969#42432 · In reply to: #42430 Hi Lukas, Am Donnerstag, den 01.01.2009, 02:36 +0200 schrieb George Antoniadis: [...] > Any news on this? :) > I don't see this in 5.3 but are there any hopes for pushing this on > the HEAD of 6 sometime soon? :) Not from my side. But I think I will find time to work on it in the next few weeks. cu, Lars -- Jabber: lars@strojny.net Weblog: http://usrportage.de --- ## #42433 — Marcus Boerger — 2009-01-01T13:56:31+00:00 URL: https://externals.io/message/39969#42433 · In reply to: #42431 Hello Lukas, if anything requires an internal API change than we at least should do those parts. Besides this issue was long ago raised and imo should go in. As we get more and more people testing what 5.3 will be we get more and more complains about the lack of these. And isn't that the goal of an alpha verison as well? marcus Thursday, January 1, 2009, 3:53:02 AM, you wrote: > > > […] > Stas reviewed the patch and determined that it needs a bit more work. > Its too late for 5.3 I would say now, but the main stumbling point is > the lack of a proper patch. Its still noted on the "future PHP > releases" 5.3 todo wiki page. > regards, > Lukas Best regards, Marcus --- ## #42440 — Pierre Joye — 2009-01-01T16:55:05+00:00 URL: https://externals.io/message/39969#42440 · In reply to: #42433 hi! > Hello Lukas, > > if anything requires an internal API change than we at least should do > those parts. Besides this issue was long ago raised and imo should go in. > As we get more and more people testing what 5.3 will be we get more and > more complains about the lack of these. And isn't that the goal of an alpha > verison as well? Agreed. We should actually do a feature freeze after the 1st beta/RC. However, issues like this one should be fixed too after beta/RC, it would be bad to introduce new inconsistencies, saw them during the RC phase but leave them in only because we are in the RC. and best wishes for 2k9! :) Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #42444 — Lukas Kahwe Smith — 2009-01-02T13:59:40+00:00 URL: https://externals.io/message/39969#42444 · In reply to: #42440 > hi! > > > > […] > > Agreed. We should actually do a feature freeze after the 1st beta/RC. > However, issues like this one should be fixed too after beta/RC, it > would be bad to introduce new inconsistencies, saw them during the RC > phase but leave them in only because we are in the RC. > > and best wishes for 2k9! :) @Marcus: Like I said its a question of someone writing the code .. Timm proposed a patch which Stas thought had issues and then nobody picked things up .. @Pierre/all: Well we did announce something like a freeze. Of course there are still changes going in undiscussed and for the most part this is ok (and not doing those changes would be a bad idea and unnecessary to be delayed). However I would really appreciate it if people would really think about the changes they are doing. Think twice about changes that can introduce a regression or a lot of work and ask if the change has any change of being problematic. In this light the `dl()` change by Marcus (AFAIK this was planned and done for 6.0 and not 5.3) and the windows PCRE change by Andi seem potential candidates for regressions, issues and maybe should have been discussed beforehand. Just using these two has an example since they are the two last commits I marked as potential issues. BTW: I was planning on sending out a mail on Monday about beta1. Johannes and I feel like a release on the 20th or 22nd seems realistic. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #42445 — Marcus Boerger — 2009-01-02T14:20:03+00:00 URL: https://externals.io/message/39969#42445 · In reply to: #42444 Hello Lukas, Friday, January 2, 2009, 2:59:40 PM, you wrote: > > > […] > @Marcus: Like I said its a question of someone writing the code .. > Timm proposed a patch which Stas thought had issues and then nobody > picked things up .. There are two things here. One is the __getStatic which I do not care for personally but which has the potential of requiring c level api changes. The other is 'static class' as in the patch provided by Lars. That looks pretty good to me and from what I can tell Lars addressed all of the issues raised by Stas (a lot were referring to __getStatic anyway). http://lars.schokokeks.org/php/static-classes-002.diff Since this one would imo bring a nice addition in regards to handling consts as a better choice than defines I'd like to see it in. Also only this one seems ready. The __getStatic() indeed seems much more complicated as outlined by Stas in detail. marcus > @Pierre/all: Well we did announce something like a freeze. Of course > there are still changes going in undiscussed and for the most part > this is ok (and not doing those changes would be a bad idea and > unnecessary to be delayed). However I would really appreciate it if > people would really think about the changes they are doing. Think > twice about changes that can introduce a regression or a lot of work > and ask if the change has any change of being problematic. > In this light the `dl()` change by Marcus (AFAIK this was planned and > done for 6.0 and not 5.3) and the windows PCRE change by Andi seem > potential candidates for regressions, issues and maybe should have > been discussed beforehand. Just using these two has an example since > they are the two last commits I marked as potential issues. Postponing changes that prevent SEGVs for the sake of versioning and that cannot easily be done later because they require c level api changes is a no go for me. > BTW: I was planning on sending out a mail on Monday about beta1. > Johannes and I feel like a release on the 20th or 22nd seems realistic. > regards, > Lukas Kahwe Smith > mls@pooteeweet.org Best regards, Marcus --- ## #42446 — Pierre Joye — 2009-01-02T14:52:06+00:00 URL: https://externals.io/message/39969#42446 · In reply to: #42444 hi, > @Marcus: Like I said its a question of someone writing the code .. Timm > proposed a patch which Stas thought had issues and then nobody picked things > up .. > > @Pierre/all: Well we did announce something like a freeze. Of course there > are still changes going in undiscussed and for the most part this is ok (and > not doing those changes would be a bad idea and unnecessary to be delayed). > However I would really appreciate it if people would really think about the > changes they are doing. Think twice about changes that can introduce a > regression or a lot of work and ask if the change has any change of being > problematic. We all agree here, maybe not being too strict when it comes to extensions. Breakages in an ext can be reverted at any stage (almost any). > In this light the `dl()` change by Marcus (AFAIK this was planned and done for > 6.0 and not 5.3) and the windows PCRE change by Andi seem potential > candidates for regressions, issues and maybe should have been discussed > beforehand. Just using these two has an example since they are the two last > commits I marked as potential issues. If we can't test such changes in the current release phase, then we will never be able to do anything sane. Alpha releases are mainly marketing releases, if I can say so. Only very few actually tests them in comparison to beta or RC. About the dl issue, I think it is a good idea to drop it in 5.3. It never worked anyway and causes all kind of side effects (the worst being segv). However, it would have been preferable to post a little note on internals before, for the principle :) > BTW: I was planning on sending out a mail on Monday about beta1. Johannes > and I feel like a release on the 20th or 22nd seems realistic. Sounds fine for me too. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #42447 — Lukas Kahwe Smith — 2009-01-02T14:53:09+00:00 URL: https://externals.io/message/39969#42447 · In reply to: #42445 > There are two things here. One is the __getStatic which I do not care > for personally but which has the potential of requiring c level api > changes. The other is 'static class' as in the patch provided by Lars. > That looks pretty good to me and from what I can tell Lars addressed > all of the issues raised by Stas (a lot were referring to __getStatic > anyway). > http://lars.schokokeks.org/php/static-classes-002.diff > Since this one would imo bring a nice addition in regards to handling > consts as a better choice than defines I'd like to see it in. Also > only this one seems ready. The __getStatic() indeed seems much more > complicated as outlined by Stas in detail. Ok, I guess I totally missed the "static class" patch. @Lars: Could you open a new thread and start a discussion about that patch there? > > > […] > > Postponing changes that prevent SEGVs for the sake of versioning and > that cannot easily be done later because they require c level api > changes is a no go for me. Well we for some reason scheduled the change for `dl()` PHP 6.0 ("enable `dl()` only when a SAPI layer registers it explicitly"). I do not remember why we did not schedule it for the next PHP release (maybe we just thought PH 6.0 would be the next release) or if we did not want to make this change in 5.x. I just noted it as a commit that probably should have been mentioned on the list before being committed. regards, Lukas Kahwe Smith mls@pooteeweet.org --- Next page: https://externals.io/message/39969.md?page=2