Call non-static method staticly raise E_STRICT, but why call a static method instancely won't

14 years ago by reeze — view source

unread

Hi,
I am not sure it's the right place to discuss this. someday I found I call a static method instancely.
the method is just a helper method when reviewing my code. I know I do the wrong thing, but PHP doesn't
complain about it. then I do some tests like below:

<?php
error_reporting(E_ALL ^ E_STRICT);
class A {
public function static staticFunc() {
echo "static";
}
public function instanceFunc() {
echo "instace";
}
}

A::instanceFunct(); // Strict Standards: Non-static method A::instanceFunc() ...
$a = new A();
$a->staticFunc(); // Just static no E_STRICT error raised

I know it's the wrong way to do like these, maybe there are some historical reasons to allow these.
I just wonder why previous method call raise E_STRICT but later not.

Yes, something could be done doesn't means we should, but we could stop things like happened.

http://reeze.cn

14 years ago by keisial@gmail.com — view source

unread

reeze wrote:

Hi,
I am not sure it's the right place to discuss this. someday I found I call a static method instancely.
the method is just a helper method when reviewing my code. I know I do the wrong thing, but PHP doesn't
complain about it. then I do some tests like below:

A few corrections to your test case so it actually works.

<?php
error_reporting(E_ALL ^ E_STRICT);
I think you want E_ALL | E_STRICT

class A {
public function static staticFunc() {
This is a parse error. static should be placed before function.

echo "static";
}
public function instanceFunc() {
echo "instace";
}
}

A::instanceFunct(); // Strict Standards: Non-static method A::instanceFunc() ...
And this should be A::instanceFunc();

$a = new A();
$a->staticFunc(); // Just static no E_STRICT error raised

I know it's the wrong way to do like these, maybe there are some historical reasons to allow these.
I just wonder why previous method call raise E_STRICT but later not.

Yes, something could be done doesn't means we should, but we could stop things like happened.

I think it may be related to inheritance.

14 years ago by Alessandro Nadalin — view source

unread

2011/4/24 Etienne Kneuss colder@php.net:

Hi,

reeze wrote:

Hi,
I am not sure it's the right place to discuss this. someday I found I call a static method instancely.
the method is just a helper method when reviewing my code. I know I do the wrong thing, but PHP doesn't
complain about it. then I do some tests like below:

A few corrections to your test case so it actually works.

<?php
error_reporting(E_ALL ^ E_STRICT);
I think you want E_ALL | E_STRICT

class A {
public function static staticFunc() {
This is a parse error. static should be placed before function.

echo "static";
}
public function instanceFunc() {
echo "instace";
}
}

A::instanceFunct(); // Strict Standards: Non-static method A::instanceFunc() ...
And this should be A::instanceFunc();

$a = new A();
$a->staticFunc(); // Just static no E_STRICT error raised

I know it's the wrong way to do like these, maybe there are some historical reasons to allow these.
I just wonder why previous method call raise E_STRICT but later not.

Hi Etienne,

Nothing wrong with it.

The E_STRICT is raised because when you call a non-static method
statically, $this will not be defined and that could be a problem (e.g.
the method could rely on it). When you call a static method with ->, it
remains a static call, $this will not be defined anyway, and there is
absolutely no problem with it.

I can see your point, but I think we should drop this "feature" not to
let developers have N ways of doing the same things: if you declare a
method as static, you should be able to only call it with a static
call, not hrough an object.

PHP usually lets you do the same thing in a few ways, and that's a bit
frustrating, because we should force some kind of best practices for
the language: not .advise, but force.

My 2 cents,

Best,

Yes, something could be done doesn't means we should, but we could stop things like happened.

I think it may be related to inheritance.

--

--

--
Nadalin Alessandro
www.odino.org
www.twitter.com/odino

14 years ago by Reindl Harald — view source

unread

Am 25.04.2011 09:52, schrieb Alessandro Nadalin:

Nothing wrong with it.

The E_STRICT is raised because when you call a non-static method
statically, $this will not be defined and that could be a problem (e.g.
the method could rely on it). When you call a static method with ->, it
remains a static call, $this will not be defined anyway, and there is
absolutely no problem with it.

I can see your point, but I think we should drop this "feature" not to
let developers have N ways of doing the same things:

why should ANYTHING be dropped affection backward compatibility?

if you declare a method as static, you should be able to only call it
with a static call, not hrough an object.

that is a opinion, but not enough to damage BC

PHP usually lets you do the same thing in a few ways, and that's a bit
frustrating

there are so naby different woman and cars out there and that's a
bit frustrating - you know what i mean?

because we should force some kind of best practices for
the language: not .advise, but force

maybe you are using the wrong language if this is your opinion?
nobody says "stop selling guns because somebody can shoot in his foot"

14 years ago by Alessandro Nadalin — view source

unread

Hi Harald,

I can see your point, but I think we should drop this "feature" not to
let developers have N ways of doing the same things:

why should ANYTHING be dropped affection backward compatibility?

if you declare a method as static, you should be able to only call it
with a static call, not hrough an object.

that is a opinion, but not enough to damage BC

I think this should be the subject to talk about, whether or not this
is something we accept to break retro-compatibility for.

PHP usually lets you do the same thing in a few ways, and that's a bit
frustrating

there are so naby different woman and cars out there and that's a
bit frustrating - you know what i mean?

definitely not

The main point is to force developers to follow some practices, like
when you type-hint a core method of your framework (just an example
here) others can extend, instead, for example, of doing class-oriented
programming.

because we should force some kind of best practices for
the language: not .advise, but force

maybe you are using the wrong language if this is your opinion?
nobody says "stop selling guns because somebody can shoot in his foot"

That's why in lots of countries you should demonstrate to the
competent authority that you are able to manage a gun in order to get
it :)

peacefully talking, no need to be such aggressive

--
Nadalin Alessandro
www.odino.org
www.twitter.com/odino

14 years ago by Reindl Harald — view source

unread

Am 25.04.2011 13:17, schrieb Alessandro Nadalin:

peacefully talking, no need to be such aggressive

nobody is aggressive, maybe it sounds do for you because english
is not my native language and it is not always easy to make
a position clear in a foreign language in the same way as in
the native one

14 years ago by Richard Quadling — view source

unread

nobody says "stop selling guns because somebody can shoot in his foot"

It'd be a place to start though.

--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY

14 years ago by Martin Scotta — view source

unread

Martin Scotta

On Mon, Apr 25, 2011 at 4:52 AM, Alessandro Nadalin <
alessandro.nadalin@gmail.com> wrote:

2011/4/24 Etienne Kneuss colder@php.net:

Hi,

reeze wrote:

Hi,
I am not sure it's the right place to discuss this. someday I found I
call a static method instancely.
the method is just a helper method when reviewing my code. I know I do
the wrong thing, but PHP doesn't
complain about it. then I do some tests like below:

A few corrections to your test case so it actually works.

<?php
error_reporting(E_ALL ^ E_STRICT);
I think you want E_ALL | E_STRICT

class A {
public function static staticFunc() {
This is a parse error. static should be placed before function.

echo "static";
}
public function instanceFunc() {
echo "instace";
}
}

A::instanceFunct(); // Strict Standards: Non-static method
A::instanceFunc() ...
And this should be A::instanceFunc();

$a = new A();
$a->staticFunc(); // Just static no E_STRICT error raised

I know it's the wrong way to do like these, maybe there are some
historical reasons to allow these.
I just wonder why previous method call raise E_STRICT but later not.

Hi Etienne,

Nothing wrong with it.

The E_STRICT is raised because when you call a non-static method
statically, $this will not be defined and that could be a problem (e.g.
the method could rely on it). When you call a static method with ->, it
remains a static call, $this will not be defined anyway, and there is
absolutely no problem with it.

I can see your point, but I think we should drop this "feature" not to
let developers have N ways of doing the same things: if you declare a
method as static, you should be able to only call it with a static
call, not hrough an object.

PHP usually lets you do the same thing in a few ways, and that's a bit
frustrating, because we should force some kind of best practices for
the language: not .advise, but force.

My 2 cents,

Back in PHP4 it was the only way to "simulate" an static call, but
nowadays it really don't make sense at all.

class Foo {
static function toString(Bar $bar) {
return 'Foo::toString($bar)';
}
function toString() {
return '$this->toString()';
}
}

$foo = new Foo();
echo $foo->toString(); // instance
echo Foo::toString(); // class

PHP will complain about the 2nd method (can't redefine function) but for me
are 2 completely different methods.
I belive the current Object Model could be improved. isn't?

Best,

Yes, something could be done doesn't means we should, but we could
stop things like happened.

I think it may be related to inheritance.

--

--

--
Nadalin Alessandro
www.odino.org
www.twitter.com/odino

14 years ago by Ben Schmidt — view source

unread

Back in PHP4 it was the only way to "simulate" an static call, but
nowadays it really don't make sense at all.

class Foo {
static function toString(Bar $bar) {
return 'Foo::toString($bar)';
}
function toString() {
return '$this->toString()';
}
}

$foo = new Foo();
echo $foo->toString(); // instance
echo Foo::toString(); // class

PHP will complain about the 2nd method (can't redefine function) but for me
are 2 completely different methods.
I belive the current Object Model could be improved. isn't?

I agree. Backward compatibility is the only reason to keep this. It's a
pretty compelling reason, though. It's hard to know how to phase it out
"non-invasively", too.

Ben.

14 years ago by David Muir — view source

unread

Back in PHP4 it was the only way to "simulate" an static call, but
nowadays it really don't make sense at all.

class Foo {
static function toString(Bar $bar) {
return 'Foo::toString($bar)';
}
function toString() {
return '$this->toString()';
}
}

$foo = new Foo();
echo $foo->toString(); // instance
echo Foo::toString(); // class

PHP will complain about the 2nd method (can't redefine function) but
for me
are 2 completely different methods.
I belive the current Object Model could be improved. isn't?

I agree. Backward compatibility is the only reason to keep this. It's a
pretty compelling reason, though. It's hard to know how to phase it out
"non-invasively", too.

Ben.

Why not just deprecate it, and throw a E_STRICT warning? That's how
we're dealing with all other future BC breaks.

David

14 years ago by reeze — view source

unread

Back in PHP4 it was the only way to "simulate" an static call, but
nowadays it really don't make sense at all.

class Foo {
static function toString(Bar $bar) {
return 'Foo::toString($bar)';
}
function toString() {
return '$this->toString()';
}
}

$foo = new Foo();
echo $foo->toString(); // instance
echo Foo::toString(); // class

PHP will complain about the 2nd method (can't redefine function) but
for me
are 2 completely different methods.
I belive the current Object Model could be improved. isn't?

I agree. Backward compatibility is the only reason to keep this. It's a
pretty compelling reason, though. It's hard to know how to phase it out
"non-invasively", too.

Ben.

Why not just deprecate it, and throw a E_STRICT warning? That's how
we're dealing with all other future BC breaks.
+1 just like call non-static method statically did

David