Re: [PHP-DEV] Call non-static method staticly raise E_STRICT, but why call a static method instancely won't
2011/4/24 Etienne Kneuss col...@php.net:
Hi,
On Apr 24 22:13:47, Ángel González wrote:
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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Nadalin Alessandro
www.odino.org
www.twitter.com/_odino_
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call non-static method staticly raise E_STRICT, but why call a static method instancely won't
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 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Call non-static method staticly raise E_STRICT, but why call a static method instancely won't
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_ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call non-static method staticly raise E_STRICT, but why call a static method instancely won't
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 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Call non-static method staticly raise E_STRICT, but why call a static method instancely won't
Martin Scotta
On Mon, Apr 25, 2011 at 4:52 AM, Alessandro Nadalin
alessandro.nada...@gmail.com wrote:
2011/4/24 Etienne Kneuss col...@php.net:
Hi,
On Apr 24 22:13:47, Ángel González wrote:
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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Nadalin Alessandro
www.odino.org
www.twitter.com/_odino_
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call non-static method staticly raise E_STRICT, but why call a static method instancely won't
On 25 April 2011 11:29, Reindl Harald h.rei...@thelounge.net wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call non-static method staticly raise E_STRICT, but why call a static method instancely won't
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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call non-static method staticly raise E_STRICT, but why call a static method instancely won't
On 26/04/11 09:37, Ben Schmidt wrote:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call non-static method staticly raise E_STRICT, but why call a static method instancely won't
On 2011年4月26日星期二 at 上午10:31, David Muir wrote:
On 26/04/11 09:37, Ben Schmidt wrote:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call non-static method staticly raise E_STRICT, but why call a static method instancely won't
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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call non-static method staticly raise E_STRICT, but why call a static method instancely won't
Hi,
On Apr 24 22:13:47, Ángel González wrote:
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.
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.
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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Call non-static method staticly raise E_STRICT, but why call a static method instancely won't
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
