Static and non-static methods

php.internals

Andrei Zmievski

23 years ago
What does everyone think about disallowing non-instance calls to methods which are not declared static? Currently, this works: class A { function B() { return 1; } } A::B(); But really, if B was intended to be used that way, it should have been declared as static. -Andrei http://www.gravitonic.com/ * If it ain't broken, it doesn't have enough features yet. *

John Coggeshall

23 years ago
>What does everyone think about disallowing non-instance calls >to methods which are not declared static? Currently, this works:
I like the idea, but wouldn't that cause some problems with BC? -~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~- John Coggeshall john at coggeshall dot org http://www.coggeshall.org/ -~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-

Sterling Hughes

23 years ago
On Fri, 2003-04-04 at 09:52, Andrei Zmievski wrote:
> What does everyone think about disallowing non-instance calls to methods > which are not declared static? Currently, this works: > > class A { > function B() { return 1; } > } > > A::B(); > > But really, if B was intended to be used that way, it should have been > declared as static. >
Well its a BC nightmare, and I don't really see any big advantage. -Sterling
> -Andrei http://www.gravitonic.com/ > * If it ain't broken, it doesn't have enough features yet. *
-- "Reductionists like to take things apart. The rest of us are just trying to get it together." - Larry Wall, Programming Perl, 3rd Edition

Derick Rethans

23 years ago
On Fri, 4 Apr 2003, Sterling Hughes wrote:
> On Fri, 2003-04-04 at 09:52, Andrei Zmievski wrote: > > What does everyone think about disallowing non-instance calls to methods > > which are not declared static? Currently, this works: > > > > class A { > > function B() { return 1; } > > } > > > > A::B(); > > > > But really, if B was intended to be used that way, it should have been > > declared as static. > > > > Well its a BC nightmare, and I don't really see any big advantage.
Agreed, breaking BC for this sounds like a bad idea to me. Derick
-- "my other box is your windows PC" ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ -------------------------------------------------------------------------

Andrei Zmievski

23 years ago
On Fri, 04 Apr 2003, Derick Rethans wrote:
> > Well its a BC nightmare, and I don't really see any big advantage. > > Agreed, breaking BC for this sounds like a bad idea to me.
<vent> sometimes I just hate BC.. </vent> -Andrei http://www.gravitonic.com/ * Use the source, Luke. *

Per Lundberg

23 years ago
On Fri, 2003-04-04 at 18:07, Andrei Zmievski wrote:
> On Fri, 04 Apr 2003, Derick Rethans wrote: > > > Well its a BC nightmare, and I don't really see any big advantage. > > Agreed, breaking BC for this sounds like a bad idea to me. > <vent> sometimes I just hate BC.. </vent>
Why only sometimes? Besides, it is much a matter of asking yourself: what is most important, being compatible with old PHP ugly-OO code or compatibility with other OO-languages such as C++ and Java? I know what I would answer to that question. :-)
-- Best regards, Per Lundberg / Capio ApS Phone: +46-18-4186040 Fax: +46-18-4186049 Web: http://www.nobolt.com

J Smith

23 years ago
It's been said before, but PHP isn't C++ or Java, so why would they have to be compatible? J Per Lundberg wrote:

Per Lundberg

23 years ago
On Fri, 2003-04-04 at 19:06, J Smith wrote:
> It's been said before, but PHP isn't C++ or Java, so why would they have to > be compatible?
Because it will make it easier for C++ or Java programmers to find PHP a pleasant experience. I think much of the discussion of where PHP should go is a bit misleading, actually. Zeev and Andi (and others probably) believe it is important to keep PHP being easy to learn by newcomers. Yes, of course, I agree to that. Still, I do not come from this kind of background (PHP was my 8th programming language -- Basic, x86 assembly, Pascal, C, C++, Perl and Java in that order) and I really think it is an unwise idea to only focus on being able to learn for people with little or no programming experience. It is equally important, in my eyes, to make it convenient for people with a different background, such as mine. It will make PHP more attractive for advanced programmers. Regarding this specific patch, I think it is a very very good idea since it removes one of the very "weird" features of PHP OO, where I think it is really far too relaxed. This is one of the big weaknesses of Perl I think (ultra-relaxed OO). Of course, the PHP OO in ZendEngine2 is greatly improved, but still, things like this can make experienced OO programmers with C++ or Java background just shudder and say "it's a toy". I don't think that's good.
-- Best regards, Per Lundberg / Capio ApS Phone: +46-18-4186040 Fax: +46-18-4186049 Web: http://www.nobolt.com

J Smith

23 years ago
Once you start down that route, where will it end? When PHP's object model is 100% compatible with Java and C++ (which is obviously impossible given the differences between the two)? Or perhaps it should be made compatible with Ruby or SmallTalk, so experienced Ruby and SmallTalk programmers will have a more pleasant PHP experience? One the main reasons for PHP's popularity is that it is easy for the newcomers. Sure, there are many advanced and experienced developers using PHP, but I'm assuming that they aren't in the majority. As for this specific patch, BC is the main concern. Then again, with all of the changes to the object model, maybe this would be a good time to implement the change, as BC is going to be broken anyway, but it should be for a better reason than appeasing C++ and Java programmers. J Per Lundberg wrote:

Rasmus Lerdorf

23 years ago
On Fri, 4 Apr 2003, Per Lundberg wrote:
> On Fri, 2003-04-04 at 19:06, J Smith wrote: > > It's been said before, but PHP isn't C++ or Java, so why would they have to > > be compatible? > > Because it will make it easier for C++ or Java programmers to find PHP a > pleasant experience.
Only the people looking for purity and aesthetic beauty. I hate to break it to you, but PHP is an ugly language. It is always going to be an ugly language. Ugly problems often need ugly solutions because the pretty solution is sometimes just too much of a hassle for everyone involved. There are many examples of this uglyness. Case-insentive function names is one, you are arguing that this is another. But look at it from the real world and not from the purist looking for beauty. Does it really matter that you can't make two functions that only differ by case? Are you really going to have foo() and Foo() in the same code doing different things? Along the same lines, why do you care if you can call a static method in a class without declaring it static? Other languages, or some CS prof somewhere told you it was uncool, but so what? It isn't going to change the way your code runs or the way anybody uses the language. If we were starting from scratch at this point, sure, some of these things would be done differently, but we have a bunch of legacy code out there, and when choosing whether to break backward compatibility we need to look long and hard at why we are doing so in each case. If the only answer is for purity or aesthetic beauty reasons, we are very likely to always choose the uglier BC road. -Rasmus

Sebastian Bergmann

23 years ago
Rasmus Lerdorf wrote:
> Along the same lines, why do you care if you can call a static method > in a class without declaring it static?
A warning would be nice. After all declaring a static method explicitly static using the appropriate keyword improves performance (a bit) because $this doesn't have to be initialized etc.
-- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

Derick Rethans

23 years ago
On Fri, 4 Apr 2003, Per Lundberg wrote:
> On Fri, 2003-04-04 at 18:07, Andrei Zmievski wrote: > > On Fri, 04 Apr 2003, Derick Rethans wrote: > > > > Well its a BC nightmare, and I don't really see any big advantage. > > > Agreed, breaking BC for this sounds like a bad idea to me. > > <vent> sometimes I just hate BC.. </vent> > > Why only sometimes? > > Besides, it is much a matter of asking yourself: what is most important, > being compatible with old PHP ugly-OO code or compatibility with other > OO-languages such as C++ and Java? > > I know what I would answer to that question. :-)
Yes, "being compatible" Derick
-- "my other box is your windows PC" ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ -------------------------------------------------------------------------

Derick Rethans

23 years ago
On Fri, 4 Apr 2003, Andrei Zmievski wrote:
> On Fri, 04 Apr 2003, Derick Rethans wrote: > > > Well its a BC nightmare, and I don't really see any big advantage. > > > > Agreed, breaking BC for this sounds like a bad idea to me. > > <vent> sometimes I just hate BC.. </vent>
heh, me too :) Derick
-- "my other box is your windows PC" ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ -------------------------------------------------------------------------

(Marcus Börger)

23 years ago
At 18:07 04.04.2003, Andrei Zmievski wrote:
>On Fri, 04 Apr 2003, Derick Rethans wrote: > > > Well its a BC nightmare, and I don't really see any big advantage. > > > > Agreed, breaking BC for this sounds like a bad idea to me. > ><vent> sometimes I just hate BC.. </vent>
Sometimes as in this case BC means sticking to "it's not a bug it's a feature". In PHP 4 oo was nothing more than structures with a not thought out possibility to attach normal functions. Since we now seem to reach a very good oo level, why shouldn't we remove such crap? I mean every code that uses oo will be rewritten anyway. marcus

Andi Gutmans

23 years ago
At 01:12 PM 4/5/2003 +0200, Marcus Börger wrote:
>At 18:07 04.04.2003, Andrei Zmievski wrote: >>On Fri, 04 Apr 2003, Derick Rethans wrote: >> > > Well its a BC nightmare, and I don't really see any big advantage. >> > >> > Agreed, breaking BC for this sounds like a bad idea to me. >> >><vent> sometimes I just hate BC.. </vent> > > >Sometimes as in this case BC means sticking to "it's not a bug it's a >feature". >In PHP 4 oo was nothing more than structures with a not thought out >possibility >to attach normal functions. > >Since we now seem to reach a very good oo level, why shouldn't we remove such >crap? I mean every code that uses oo will be rewritten anyway.
Marcus, You and all the rest who want to break BC on this issue are welcome to use static in your code. IMO, nothing prevents you from writing nice OO code. It's not as if this is forcing you not to use static. Andi

Andrei Zmievski

23 years ago
On Sat, 05 Apr 2003, Andi Gutmans wrote:
> Marcus, > > You and all the rest who want to break BC on this issue are welcome to use > static in your code. > IMO, nothing prevents you from writing nice OO code. It's not as if this is > forcing you not to use static.
Do you have a suggestion then for how I should handle the case where a non-static method is called as if it were static? Should the method throw an exception, a notice, an error? -Andrei http://www.gravitonic.com/ * Programming is an art form that fights back. *

Andi Gutmans

23 years ago
At 11:02 AM 4/7/2003 -0400, Andrei Zmievski wrote:
>On Sat, 05 Apr 2003, Andi Gutmans wrote: > > Marcus, > > > > You and all the rest who want to break BC on this issue are welcome to use > > static in your code. > > IMO, nothing prevents you from writing nice OO code. It's not as if > this is > > forcing you not to use static. > >Do you have a suggestion then for how I should handle the case where a >non-static method is called as if it were static? Should the method >throw an exception, a notice, an error?
If you ask me, I think an error would be appropriate. Andi

(Marcus Börger)

23 years ago
At 14:52 05.04.2003, Andi Gutmans wrote:
>At 01:12 PM 4/5/2003 +0200, Marcus Börger wrote: >>At 18:07 04.04.2003, Andrei Zmievski wrote: >>>On Fri, 04 Apr 2003, Derick Rethans wrote: >>> > > Well its a BC nightmare, and I don't really see any big advantage. >>> > >>> > Agreed, breaking BC for this sounds like a bad idea to me. >>> >>><vent> sometimes I just hate BC.. </vent> >> >> >>Sometimes as in this case BC means sticking to "it's not a bug it's a >>feature". >>In PHP 4 oo was nothing more than structures with a not thought out >>possibility >>to attach normal functions. >> >>Since we now seem to reach a very good oo level, why shouldn't we remove such >>crap? I mean every code that uses oo will be rewritten anyway. > >Marcus, > >You and all the rest who want to break BC on this issue are welcome to use >static in your code. >IMO, nothing prevents you from writing nice OO code. It's not as if this >is forcing you not to use static.
I know :-) The reason not only i want to break BC here is to prevent users from shooting in their knees and blaming php for the erors in bug-reports later. marcus

Andi Gutmans

23 years ago
At 03:29 PM 4/5/2003 +0200, Marcus Börger wrote:
>At 14:52 05.04.2003, Andi Gutmans wrote: >>At 01:12 PM 4/5/2003 +0200, Marcus Börger wrote: >>>At 18:07 04.04.2003, Andrei Zmievski wrote: >>>>On Fri, 04 Apr 2003, Derick Rethans wrote: >>>> > > Well its a BC nightmare, and I don't really see any big advantage. >>>> > >>>> > Agreed, breaking BC for this sounds like a bad idea to me. >>>> >>>><vent> sometimes I just hate BC.. </vent> >>> >>> >>>Sometimes as in this case BC means sticking to "it's not a bug it's a >>>feature". >>>In PHP 4 oo was nothing more than structures with a not thought out >>>possibility >>>to attach normal functions. >>> >>>Since we now seem to reach a very good oo level, why shouldn't we remove >>>such >>>crap? I mean every code that uses oo will be rewritten anyway. >> >>Marcus, >> >>You and all the rest who want to break BC on this issue are welcome to >>use static in your code. >>IMO, nothing prevents you from writing nice OO code. It's not as if this >>is forcing you not to use static. > > >I know :-) > >The reason not only i want to break BC here is to prevent users from >shooting in their knees and >blaming php for the erors in bug-reports later.
Let's leave this to the documentation team. We should encourage the use of "static" for static methods. Andi