Re: __getStatic

Hello Lukas, Friday, January 2, 2009, 2:59:40 PM, you wrote: > On 01.01.2009, at 17:55, Pierre Joye wrote: >> hi! >> >> On Thu, Jan 1, 2009 at 2:56 PM, Marcus Boerger <helly@php.net> wrote: >>> 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! :) > @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