Static method vs Non Static method

[gg9h0st]

i really wander what makes static method special?

in fact i can access a non static method statically using '::'

class aclass {
function anonstatic() {
echo 'non static';
}

static function astatic() {
echo 'static';
}
}

$aobj = new aclass();

aclass::anonstatic();
//it works.

$aobj->astatic();
//it works too.

i see a diffrence that i can't use $this in static method but nothing.

i don't feel there's no reason i have to make a mothod static.

is there any reason i have to declare a mothod as static?

apache2.0/php5.14

[Oli Filth]

gg9h0st said the following on 26/05/2006 09:36:

i really wander what makes static method special?

in fact i can access a non static method statically using '::'

class aclass {
function anonstatic() {
echo 'non static';
}

static function astatic() {
echo 'static';
}
}

$aobj = new aclass();

aclass::anonstatic();
//it works.

$aobj->astatic();
//it works too.

i see a diffrence that i can't use $this in static method but nothing.

i don't feel there's no reason i have to make a mothod static.

is there any reason i have to declare a mothod as static?

Static methods and variables are useful when you want to share
information between objects of a class, or want to represent something
that's related to the class itself, not any particular object.

For some reason, PHP allows you to call non-static and static methods
interchangeably, which as far as I can see, makes *no* sense at all,
neither from a semantic nor a programmatic point of view.
--
Oli

[Chung Leong]

gg9h0st wrote:

i really wander what makes static method special?

Nothing. It's mainly for documentation purpose. I mean, you don't
really need to declare class variable either. IIRC static methods will
show up in a separate section when class info is retrieved through the
reflection API.

Often times in PHP you can do funky things simply because it's not
worth the effort to stop funk.

[Oli Filth]

Chung Leong said the following on 26/05/2006 17:05:

gg9h0st wrote:

i really wander what makes static method special?

Nothing. It's mainly for documentation purpose. I mean, you don't
really need to declare class variable either. IIRC static methods will
show up in a separate section when class info is retrieved through the
reflection API.

Often times in PHP you can do funky things simply because it's not
worth the effort to stop funk.

If I understand your allusion correctly, in some ways, I'd say it's the
other way round. PHP lets you do a lot of unfunky things because the
developers didn't like the idea of being seen to enforce "funkiness" on
those uninitiated in the ways of funkiness, even though disciplined
funkiness would have been for their own good! IMO, the
static/non-static confusion and ability to add object variables
willy-nilly are two perfect examples of this in PHP.
Static members mean a lot more than that just a neat way of accessing
them separately via reflection, it's just that PHP has managed to
confuse the issue by letting the programmer do weird things for no good
reason. "Stricter" OO languages such as C++, Java, and C# that have the
concept of static members enforce them as such (being compiled
languages, they have to, obviously), and so they become a useful
"semantic" design tool, in the same way that inheritance, "abstract",
"final" and visibility specifiers are all useful, but completely
unnecessary in terms of program functionality.
--
Oli

[Chung Leong]

Oli Filth wrote:

If I understand your allusion correctly, in some ways, I'd say it's the
other way round. PHP lets you do a lot of unfunky things because the
developers didn't like the idea of being seen to enforce "funkiness" on
those uninitiated in the ways of funkiness, even though disciplined
funkiness would have been for their own good! IMO, the
static/non-static confusion and ability to add object variables
willy-nilly are two perfect examples of this in PHP.
I guess "funk" is not a very precise term :-)

What I meant was the ability to call a non-static function statically
is highly unorthodox, but it requires extra effort to stop it. The
problem is here that the class::method() syntax is overloaded: it's
used for calling static method as well as for a non-static method to
call an overridden non-static methods in the ancestor classes. To
determine if a invocation is "legal" requires checking the context in
which it was made, which has to happen at runtime, with every call.

Whether it's worth the CPU cycles to do the check is debatable. But
since the aggregation API relies on this quirk, you can't really get
rid of it now.
Static members mean a lot more than that just a neat way of accessing
them separately via reflection, it's just that PHP has managed to
confuse the issue by letting the programmer do weird things for no good
reason. "Stricter" OO languages such as C++, Java, and C# that have the
concept of static members enforce them as such (being compiled
languages, they have to, obviously), and so they become a useful
"semantic" design tool, in the same way that inheritance, "abstract",
"final" and visibility specifiers are all useful, but completely
unnecessary in terms of program functionality.

If you're saying that PHP isn't a good OO language, I wouldn't
disagree. In my opinion a lot of the additions in PHP 5 are just me-too
fluff. PHP can never be a strict language because of its dynamic
nature. When you can have constructs like this:

if($best_case_scenario) {

class Iraq extends Democracy {
public $army;
}

} else {

class Iraq extends Quagmire {
private $army;
}

}

The kinds of checks you can do at compile time are very limited. Doing
validation at runtime on the other hand is a drag on performance, which
is already low because the language is interpreted.

[Oli Filth]

Chung Leong said the following on 26/05/2006 18:48:

Oli Filth wrote:

If I understand your allusion correctly, in some ways, I'd say it's the
other way round. PHP lets you do a lot of unfunky things because the
developers didn't like the idea of being seen to enforce "funkiness" on
those uninitiated in the ways of funkiness, even though disciplined
funkiness would have been for their own good! IMO, the
static/non-static confusion and ability to add object variables
willy-nilly are two perfect examples of this in PHP.
I guess "funk" is not a very precise term :-)

Yes, it looks like I completely misinterpreted what you meant!

What I meant was the ability to call a non-static function statically
is highly unorthodox, but it requires extra effort to stop it. The
problem is here that the class::method() syntax is overloaded: it's
used for calling static method as well as for a non-static method to
call an overridden non-static methods in the ancestor classes. To
determine if a invocation is "legal" requires checking the context in
which it was made, which has to happen at runtime, with every call.
Hmm, I'd never thought about it like that. You're right of course.
However, this logic applies to any use of a function/member/method at
any point. Any time a symbol is used, PHP presumably has to interrogate
some kind of symbol table to find whether that symbol exists in the
current scope, and is legal.
<...SNIP MY POLEMIC...>
If you're saying that PHP isn't a good OO language, I wouldn't
disagree. In my opinion a lot of the additions in PHP 5 are just me-too
fluff. PHP can never be a strict language because of its dynamic
nature. When you can have constructs like this:

if($best_case_scenario) {

class Iraq extends Democracy {
public $army;
}

} else {

class Iraq extends Quagmire {
private $army;
}

}
Political connotations aside ( :) ), it's this kind of nonsense that
makes me never want to use PHP again, at times! I know that some people
see this as a useful "feature", but coming from a compiled-language
background, I see this only as a development nightmare, and a massive
limitation on language strictness, as you've already commented on...
(Just in case; yes, I know that PHP isn't the only language that does this.)

The kinds of checks you can do at compile time are very limited. Doing
validation at runtime on the other hand is a drag on performance, which
is already low because the language is interpreted.

--
Oli

[Chung Leong]

Oli Filth wrote:

Hmm, I'd never thought about it like that. You're right of course.
However, this logic applies to any use of a function/member/method at
any point. Any time a symbol is used, PHP presumably has to interrogate
some kind of symbol table to find whether that symbol exists in the
current scope, and is legal.
Well, you would have to travel up the hierarchy to see if $this is
descended from the class. Not terribly expensive, but sort of pointless
given that the code would blow out anyway as soon as $this is accessed.
And if there's a check, you can't use such nice construct as this:

class A {
private $a = "Hello world";

public function Test() {
echo $this->a;
}
}

class B {
public $a = "The end is near";

public function Test() {
A::Test();
}
}

$b = new B();
$b->Test();

Totally unorthodox, but useful in some situations.
Political connotations aside ( :) ), it's this kind of nonsense that
makes me never want to use PHP again, at times! I know that some people
see this as a useful "feature", but coming from a compiled-language
background, I see this only as a development nightmare, and a massive
limitation on language strictness, as you've already commented on...
(Just in case; yes, I know that PHP isn't the only language that does this.)

One has to make a distinction between different environments though.
With PHP, you can very quickly see the result of a script. If there's a
bug in the code, it's usually quite obvious. You don't really need
warning from the compiler as much compared to a large C++ program.