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
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
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:
i think this is a great idea and a natural candidate for addition.
-nathan
Nathan Nobbe wrote:
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: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.
Hello Timm,
Friday, August 15, 2008, 12:44:19 AM, you wrote:
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:
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
Hello Timm,
Friday, August 15, 2008, 12:44:19 AM, you wrote:
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: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
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 mls@pooteeweet.orgwrote:
Hello Timm,
Friday, August 15, 2008, 12:44:19 AM, you wrote:
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
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
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
mls@pooteeweet.orgwrote:Hello Timm,
Friday, August 15, 2008, 12:44:19 AM, you wrote:
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 wego:
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.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
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!
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
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 david.zuelke@bitextender.com
wrote: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
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
Hi,
[...__(set|get|unset|isset)static()...]
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 ..
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
Hi,
[...__(set|get|unset|isset)static()...]
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 ..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
Hi!
I've updated the patch and added some tests with it.
Looked at the patch. There's some things I noticed there:
-
_getstatic->common.fn_flags |= ~ZEND_ACC_ALLOW_STATIC;
What was the idea here? Maybe ~ is not intended? -
Do we really need ZEND_ASSIGN_CLASS opcode, can't we reuse ASSIGN_OBJ
with flag, as we do for fetches? -
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. -
In zend_std_set_static_property, why you create new property_info two
times when property does not exist? -
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. -
What would happen with foo::$bar += 1? I don't see assign-ops handled
anywhere in the patch. -
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
Hi!
I've updated the patch and added some tests with it.
Looked at the patch. There's some things I noticed there:
_getstatic->common.fn_flags |= ~ZEND_ACC_ALLOW_STATIC;
What was the idea here? Maybe ~ is not intended?Do we really need ZEND_ASSIGN_CLASS opcode, can't we reuse
ASSIGN_OBJ with flag, as we do for fetches?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.In zend_std_set_static_property, why you create new property_info
two times when property does not exist?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.
What would happen with foo::$bar += 1? I don't see assign-ops
handled anywhere in the patch.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
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
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
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
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? :)
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? :)
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
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:
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? :)
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
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
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! :)
@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
Hello Lukas,
Friday, January 2, 2009, 2:59:40 PM, you wrote:
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! :)
@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
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?
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.
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
Hi Lukas, hi Marcus,
Am Freitag, den 02.01.2009, 15:53 +0100 schrieb Lukas Kahwe Smith:
[...]
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?
Thanks for mentioning the patch but it is too early for buzz. It was
never planned for inclusion into 5.3 and needs a lot of additional work
- not even all features I planned to implement are working currently.
cu, Lars
Jabber: lars@strojny.net
Weblog: http://usrportage.de
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
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