# Call non-static method staticly raise E_STRICT, but why call a static method instancely won't - Thread: https://externals.io/message/51998 - Original archive: https://news-web.php.net/php.internals/51998 - Started by reeze on 2011-04-24T04:07:11+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #51998 — reeze — 2011-04-24T04:07:11+00:00 URL: https://externals.io/message/51998#51998 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: 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 --- ## #52002 — keisial@gmail.com — 2011-04-24T20:13:47+00:00 URL: https://externals.io/message/51998#52002 · In reply to: #51998 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. > 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. --- ## #52004 — Alessandro Nadalin — 2011-04-25T07:52:46+00:00 URL: https://externals.io/message/51998#52004 2011/4/24 Etienne Kneuss : > Hi, > > > > […] 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, > > > […] > > -- > > > > -- Nadalin Alessandro www.odino.org www.twitter.com/_odino_ --- ## #52005 — Reindl Harald — 2011-04-25T10:29:35+00:00 URL: https://externals.io/message/51998#52005 · In reply to: #52004 Am 25.04.2011 09:52, schrieb Alessandro Nadalin: > > […] > > 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" --- ## #52006 — Alessandro Nadalin — 2011-04-25T11:17:30+00:00 URL: https://externals.io/message/51998#52006 · In reply to: #52005 Hi Harald, > > […] > > why should ANYTHING be dropped affection backward compatibility? > > > […] > > 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. > > > […] > > 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. > > > […] > > 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_ --- ## #52007 — Reindl Harald — 2011-04-25T11:41:52+00:00 URL: https://externals.io/message/51998#52007 · In reply to: #52006 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 --- ## #52008 — Martin Scotta — 2011-04-25T12:24:53+00:00 URL: https://externals.io/message/51998#52008 · In reply to: #52004 Martin Scotta On Mon, Apr 25, 2011 at 4:52 AM, Alessandro Nadalin < alessandro.nadalin@gmail.com> wrote: > 2011/4/24 Etienne Kneuss : > > […] > call a static method _instancely_. > > […] > the wrong thing, but PHP doesn't > > […] > A::instanceFunc() ... > > […] > historical reasons to allow these. > > […] > > Hi Etienne, > > > […] > > 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? > > […] > stop things like happened. > > […] > > > > -- > Nadalin Alessandro > www.odino.org > www.twitter.com/_odino_ --- ## #52009 — Richard Quadling — 2011-04-25T21:32:58+00:00 URL: https://externals.io/message/51998#52009 · In reply to: #52005 > 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 --- ## #52010 — Ben Schmidt — 2011-04-26T00:37:20+00:00 URL: https://externals.io/message/51998#52010 · In reply to: #52008 > 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. --- ## #52011 — David Muir — 2011-04-26T02:31:25+00:00 URL: https://externals.io/message/51998#52011 · In reply to: #52010 > > […] > > 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 --- ## #52012 — reeze — 2011-04-26T03:30:57+00:00 URL: https://externals.io/message/51998#52012 · In reply to: #52011 > > […] > > 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