Bug #40837 [Com]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837edit=1 ID: 40837 Comment by: ed at over-yonder dot com Reported by:nick dot telford at gmail dot com Summary:static and non-static functions can't have the same name Status: Not a bug Type: Bug Package:Class/Object related Operating System: Irrelevant PHP Version:5.2.1 Block user comment: N Private report: N New Comment: Though this is old, I would like to add my own two cents. I realize that parent methods are accessed using :: as well, and this would create an ambiguity if we allowed same name usage. The problem, however, is not same name usage. The problem is that the keyword parent is the same as the keyword $this, and as such, it seems more logically sound to use parent- function than parent::function. Using the scope resolution operator logically implies the need to do so. But if we treat the parent keyword as though it is an identifier, the same way we treat object names and $this, then we can use the arrow for member functions and the scope resolution operator for static functions without ambiguity. If anything, the ambiguity / inconsistency is the use of the scope resolution operator to access member functions (which is exactly what parent::function does). In short, the usage of the scope resolution operator for parent member functions is a logical inconsistency, and the reason that parent::static and parent::member ambiguities would arise from same name capability is because of this seemingly incorrect application of scope resolution for accessing parent member functions, when a perfectly useful operator (-) already exists. In order to make compilers / interpreters handle this odd situation, they merely need to identify what things like parent and $this refer to first, which then clarifies all issues that would arise from name ambiguity, as it then allows :: and - to be distinct. Previous Comments: [2013-04-22 01:15:41] dmittner at llnw dot com Well, given the lack of similar support in other languages I can see this is an uphill battle not worth a long fight, so I'll leave with this departing thought (plus I doubt this is a proper place to debate merits of functionality changes): When I looked up this similar issue on other languages, I found people asking about it for Java and C#, and the responses fundamentally came down to the same thing: the compiler doesn't understand it. But it was clear that this is something people want in many languages, and I'd put forth that all of them doing it poorly isn't justification not to lead the charge to building a better convention. Fact is, static scope exists separate of instance scope for a reason. And if we're accepting that reason as enough to support both scopes' existence to begin with, why isn't that reason enough to take the next logical step and support resource signatures of the same name for each? Obviously using :: is out of the question and similar limitations in other languages is likely why it's not possible in them, but if we have new operators specifically to separate these, why not do it? Maybe it would put pressure on other languages to add similar support. The only remaining argument against it I could see would be one of code cleanliness and possible confusion having two methods with the same signature, but I'd have to dismiss that as minor (especially compared to overloading signatures in other languages) when there's a clear static presence on the method and the new operator on any calls to it. And with that, good day and happy programming. [2013-04-21 22:34:18] ni...@php.net @dmittner: :: is not a static access operator, it's a scope resolution operator. It calls a method (or accesses a property) in a certain scope. Conceptually that one operator is trying to do too much. That certain scope it's trying to use isn't chosen by the programmer; it's chosen by the context; by where it's being used. That's presumptuous and an unnecessary limitation. Maybe I didn't phrase that well enough. By in a certain scope I meant the class before the :: operator. In Foo::bar() the bar() method is called in the Foo scope. So, as you can see the scope *is* chosen by the programmer and no presumption takes place. :: is (AFAIK) the only way to access specifically static resources in one context, but then is also used to reference the resources of special names in other contexts. Again, this might be a misunderstanding. The scope-resolution behavior is *not* restricted to special names. It's not just about parent::foo() [and self::foo() and static::foo()], I just used that as an example as it is the most commonly used. You can do a
Bug #40837 [Com]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837edit=1 ID: 40837 Comment by: dmittner at llnw dot com Reported by:nick dot telford at gmail dot com Summary:static and non-static functions can't have the same name Status: Not a bug Type: Bug Package:Class/Object related Operating System: Irrelevant PHP Version:5.2.1 Block user comment: N Private report: N New Comment: I've got to add my vote to this feature. My use case consists of data validation methods. If called statically the validation tests are limited to things like string length, contents, etc. If called on an object it would include those tests (probably calling the static form of itself) and also comparative tests to other object conditions. I sympathize with backwards compatibility but sometimes you have to push forward. Case and point, some people I know are working with a Java-based system that doesn't support Java 7, so when building new servers they have to explicitly install an older version. Cutting a line between major PHP versions seems similarly viable. I'd also cite Magic Quotes which are completely removed in 5.4, which could similarly break older PHP4 compatibility. The precedent is set. Failing all that, how about a configuration option? Previous Comments: [2012-11-20 02:13:10] capitaine dot gloumi at gmail dot com The backward compatibility should set to deprecated any static call of object method, and use it IF NO static method with the same name exist. I use static method and object method with same name in lot of paterns, it's useful in lot of case. [2012-11-19 03:27:35] ahar...@php.net If a class is namespaced, by definition it isn't PHP 4 compatible. [2012-11-15 23:23:31] jpmarois at hotmail dot com ahar...@php.net: Sure, go Microsoft's way and move forward by staying behind for the sake of compatibility. Please explain why, As of PHP 5.3.3, methods with the same name as the last element of a namespaced class name will no longer be treated as constructor.. If PHP wont even initialize a compatible PHP 4 class anymore, how is it relevant to preserve instance methods being called statically? [2012-09-11 01:59:54] ahar...@php.net It breaks compatibility with any PHP 4 compatible code that uses static method calls. That's (obviously) less important than it once was, but there's still plenty of legacy code out there. [2012-09-10 15:29:23] mac at macnewbold dot com ahar...@php.net : What would the impacts be of deprecating static calls to non-static methods? They would seem to not make much sense, since any uses of $this inside the method (which would be pretty typical since it is a non-static method) would fail with Fatal error: Using $this when not in object context. What is the value of being able to attempt a static call on a non-static method? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=40837 -- Edit this bug report at https://bugs.php.net/bug.php?id=40837edit=1
Bug #40837 [Com]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837edit=1
ID: 40837
Comment by: ni...@php.net
Reported by:nick dot telford at gmail dot com
Summary:static and non-static functions can't have the same
name
Status: Not a bug
Type: Bug
Package:Class/Object related
Operating System: Irrelevant
PHP Version:5.2.1
Block user comment: N
Private report: N
New Comment:
We *can not* have static and non-static methods with the same name. This is
*not* just a backwards compatibility concern.
I think the issue here is that you got the meaning of the :: operator wrong. ::
is not a static access operator, it's a scope resolution operator. It calls
a method (or accesses a property) in a certain scope.
E.g. Foo::bar() calls the method bar() in the scope of class Foo. bar() here
can be any method.
A static method just means that the method does not need $this. The
Foo::bar() call will only work if
a) the method is static or
b) the method is non-static and we have a $this.
The distinction between static access operator and scope resolution
operator is important and helps you understand why some things are as they
are. For example, if you want to access a parent method, then what do you write?
parent::foo(). This means that you call foo() in the parent scope.
I get that people might argue whether calling non-static methods with :: is
useful in the general case, but calling parent methods is something everybody
should understand and find useful. And using that example it's also easy to see
why you couldn't have the same static and non-static method. Consider this
small example:
class A {
public function foo() { echo 'non-static'; }
public static function foo() { echo 'static'; }
}
class B {
public function bar() { echo parent::foo(); }
}
(new B)-bar(); // What do you get?
Allowing static and non-static methods of the same name would require us to
completely change the concept of scope-resolution and find a different way to
call parent methods etc.
So, just to say it again: Removing ::-calls to non-static methods is *not*
just a backwards compatibility issue, it would also cause problems with other,
currently used and encouraged language features.
Another thing that might help the understanding (apart from interpreting :: as
scope-resolution) is not seeing static and non-static methods as distinct
method types. Rather they are the same and static is just another method
modifier like public or final:
You probably wouldn't ask to have an abstract method and a final method of the
same name, right? Asking for a non-static and static method of the same name
makes similarly little sense. static just means doesn't need $this and
nothing more.
On a related note, this static modifier is also available for closures (i.e.
you can write $foo = static function() { ... }) and also means the same
there, that the closure does not need $this. Prefixing a closure with static
does not make it some kind of wholly different function type, it's just a
modifier. Same for the static methods ;)
I hope things are a bit clearer now.
Previous Comments:
[2013-04-21 05:30:23] dmittner at llnw dot com
I've got to add my vote to this feature.
My use case consists of data validation methods. If called statically the
validation tests are limited to things like string length, contents, etc. If
called on an object it would include those tests (probably calling the static
form of itself) and also comparative tests to other object conditions.
I sympathize with backwards compatibility but sometimes you have to push
forward. Case and point, some people I know are working with a Java-based
system
that doesn't support Java 7, so when building new servers they have to
explicitly install an older version. Cutting a line between major PHP versions
seems similarly viable.
I'd also cite Magic Quotes which are completely removed in 5.4, which could
similarly break older PHP4 compatibility. The precedent is set.
Failing all that, how about a configuration option?
[2012-11-20 02:13:10] capitaine dot gloumi at gmail dot com
The backward compatibility should set to deprecated any static call of object
method, and use it IF NO static method with the same name exist.
I use static method and object method with same name in lot of paterns, it's
useful in lot of case.
[2012-11-19 03:27:35] ahar...@php.net
If a class is namespaced, by definition it isn't PHP 4 compatible.
[2012-11-15 23:23:31] jpmarois at hotmail dot com
ahar...@php.net:
Sure, go Microsoft's
Bug #40837 [Com]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837edit=1
ID: 40837
Comment by: dmittner at llnw dot com
Reported by:nick dot telford at gmail dot com
Summary:static and non-static functions can't have the same
name
Status: Not a bug
Type: Bug
Package:Class/Object related
Operating System: Irrelevant
PHP Version:5.2.1
Block user comment: N
Private report: N
New Comment:
@ni...@php.net:
While what you write is all technically correct, I think it comes down to this
being the problem:
:: is not a static access operator, it's a scope resolution operator. It
calls a method (or accesses a property) in a certain scope.
Conceptually that one operator is trying to do too much. That certain scope
it's trying to use isn't chosen by the programmer; it's chosen by the context;
by where it's being used. That's presumptuous and an unnecessary limitation.
:: is (AFAIK) the only way to access specifically static resources in one
context, but then is also used to reference the resources of special names in
other contexts.
Clearly people want to be able to call the same method name in both an object
and static scope. It's the same reason people like function overloading: they
have logic that accomplishes the same goal but done differently--this time
based
on scope. And we'd rather not dirty our code with resource names named
differently just to identify scope.
If the :: operator can't consistently serve this purpose because it's also
having to accommodate parent and other special names, then maybe we just need
a new operator specifically for calling methods in a static scope and ONLY for
doing that.
The more I think about this the more I think :: is just broken because it's
treated inconsistently. There's probably good reasons I'm not thinking of, but
it seems :: could have always meant static scope and - could have always
meant object scope; and parent-resource would have been valid right
alongside parent::resource, each accessing the parent's resource in
legitimately different scopes.
So leave :: as it is for backwards compatibility.
Add support for - on special names for object scope and a new operator
specifically for static scope. Then we'll be able to define both object-scope
and static-scope versions of the same resources and we'll have operators to
access each consistently.
Ultimately it's not a huge deal. It'd just be nice to be able to use the same
names in both scopes. But we can at least achieve the functionality for now by
naming everything $staticVariable and staticMethod(). It's just really
gross.
Previous Comments:
[2013-04-21 09:40:32] ni...@php.net
We *can not* have static and non-static methods with the same name. This is
*not* just a backwards compatibility concern.
I think the issue here is that you got the meaning of the :: operator wrong. ::
is not a static access operator, it's a scope resolution operator. It calls
a method (or accesses a property) in a certain scope.
E.g. Foo::bar() calls the method bar() in the scope of class Foo. bar() here
can be any method.
A static method just means that the method does not need $this. The
Foo::bar() call will only work if
a) the method is static or
b) the method is non-static and we have a $this.
The distinction between static access operator and scope resolution
operator is important and helps you understand why some things are as they
are. For example, if you want to access a parent method, then what do you write?
parent::foo(). This means that you call foo() in the parent scope.
I get that people might argue whether calling non-static methods with :: is
useful in the general case, but calling parent methods is something everybody
should understand and find useful. And using that example it's also easy to see
why you couldn't have the same static and non-static method. Consider this
small example:
class A {
public function foo() { echo 'non-static'; }
public static function foo() { echo 'static'; }
}
class B {
public function bar() { echo parent::foo(); }
}
(new B)-bar(); // What do you get?
Allowing static and non-static methods of the same name would require us to
completely change the concept of scope-resolution and find a different way to
call parent methods etc.
So, just to say it again: Removing ::-calls to non-static methods is *not*
just a backwards compatibility issue, it would also cause problems with other,
currently used and encouraged language features.
Another thing that might help the understanding (apart from interpreting :: as
scope-resolution) is not seeing static and non-static methods as distinct
method types. Rather they are the same and static is just another method
modifier like public or final:
You probably wouldn't ask
Bug #40837 [Com]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837edit=1 ID: 40837 Comment by: billco at fnarg dot com Reported by:nick dot telford at gmail dot com Summary:static and non-static functions can't have the same name Status: Not a bug Type: Bug Package:Class/Object related Operating System: Irrelevant PHP Version:5.2.1 Block user comment: N Private report: N New Comment: My thoughts echo those of dmittner, while I think we all acknowledge the need for parent::method() functionality, I don't see why that small detail should invalidate this popular feature request. This seems like a limitation borrowed from C++, where it was a necessary evil of supporting multiple inheritance. PHP does not have MI and thus there was never a need for such a contrived scope resolution operator when something like Java's super would have sufficed. I can recognize that its usage dates back to the very beginning of PHP OOP, and it would be problematic to change the :: operator with all the existing code out there. Why can't we choose a new operator for pure static calls and get on with it ? It sounds like that would allow same-named static methods without ambiguity, while allowing the :: operator to continue as-is. Previous Comments: [2013-04-21 18:57:01] dmittner at llnw dot com @ni...@php.net: While what you write is all technically correct, I think it comes down to this being the problem: :: is not a static access operator, it's a scope resolution operator. It calls a method (or accesses a property) in a certain scope. Conceptually that one operator is trying to do too much. That certain scope it's trying to use isn't chosen by the programmer; it's chosen by the context; by where it's being used. That's presumptuous and an unnecessary limitation. :: is (AFAIK) the only way to access specifically static resources in one context, but then is also used to reference the resources of special names in other contexts. Clearly people want to be able to call the same method name in both an object and static scope. It's the same reason people like function overloading: they have logic that accomplishes the same goal but done differently--this time based on scope. And we'd rather not dirty our code with resource names named differently just to identify scope. If the :: operator can't consistently serve this purpose because it's also having to accommodate parent and other special names, then maybe we just need a new operator specifically for calling methods in a static scope and ONLY for doing that. The more I think about this the more I think :: is just broken because it's treated inconsistently. There's probably good reasons I'm not thinking of, but it seems :: could have always meant static scope and - could have always meant object scope; and parent-resource would have been valid right alongside parent::resource, each accessing the parent's resource in legitimately different scopes. So leave :: as it is for backwards compatibility. Add support for - on special names for object scope and a new operator specifically for static scope. Then we'll be able to define both object-scope and static-scope versions of the same resources and we'll have operators to access each consistently. Ultimately it's not a huge deal. It'd just be nice to be able to use the same names in both scopes. But we can at least achieve the functionality for now by naming everything $staticVariable and staticMethod(). It's just really gross. [2013-04-21 09:40:32] ni...@php.net We *can not* have static and non-static methods with the same name. This is *not* just a backwards compatibility concern. I think the issue here is that you got the meaning of the :: operator wrong. :: is not a static access operator, it's a scope resolution operator. It calls a method (or accesses a property) in a certain scope. E.g. Foo::bar() calls the method bar() in the scope of class Foo. bar() here can be any method. A static method just means that the method does not need $this. The Foo::bar() call will only work if a) the method is static or b) the method is non-static and we have a $this. The distinction between static access operator and scope resolution operator is important and helps you understand why some things are as they are. For example, if you want to access a parent method, then what do you write? parent::foo(). This means that you call foo() in the parent scope. I get that people might argue whether calling non-static methods with :: is useful in the general case, but calling parent methods is something everybody should understand and find useful. And using that example it's also easy to see why you couldn't have the same static
Bug #40837 [Com]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837edit=1 ID: 40837 Comment by: ni...@php.net Reported by:nick dot telford at gmail dot com Summary:static and non-static functions can't have the same name Status: Not a bug Type: Bug Package:Class/Object related Operating System: Irrelevant PHP Version:5.2.1 Block user comment: N Private report: N New Comment: @dmittner: :: is not a static access operator, it's a scope resolution operator. It calls a method (or accesses a property) in a certain scope. Conceptually that one operator is trying to do too much. That certain scope it's trying to use isn't chosen by the programmer; it's chosen by the context; by where it's being used. That's presumptuous and an unnecessary limitation. Maybe I didn't phrase that well enough. By in a certain scope I meant the class before the :: operator. In Foo::bar() the bar() method is called in the Foo scope. So, as you can see the scope *is* chosen by the programmer and no presumption takes place. :: is (AFAIK) the only way to access specifically static resources in one context, but then is also used to reference the resources of special names in other contexts. Again, this might be a misunderstanding. The scope-resolution behavior is *not* restricted to special names. It's not just about parent::foo() [and self::foo() and static::foo()], I just used that as an example as it is the most commonly used. You can do a scope-resolution call on any class in the inheritance hierarchy (e.g. a grandparent). Actually right now you could even do the call to using a scope that is outside the hierarchy, but thankfully we'll be removing that anti-feature in the next version. What we could obviously do - as you suggest - is strictly decouple scoped static method calls and scoped non-static method calls, by having a Foo::bar() syntax and a Foo-bar() syntax (e.g. parent-bar()). In my eyes that's a bad idea. We'd be adding a lot of new complexity (by making static methods *actually* different and not just a modifier of normal methods) only for the very small gain of having statics and non-statics of the same name. By the way, I just looked at a few other languages and it seems like nearly all went the same way as PHP. C++ doesn't allow it, C# doesn't allow it, Java doesn't allow it. Python doesn't really have statics, but it has the @staticmethod decorator and with that it's obviously not allowed either. The only language I looked at and which *does* support this is Ruby. So, I really don't see a solid case for this feature request. Previous Comments: [2013-04-21 21:47:20] billco at fnarg dot com My thoughts echo those of dmittner, while I think we all acknowledge the need for parent::method() functionality, I don't see why that small detail should invalidate this popular feature request. This seems like a limitation borrowed from C++, where it was a necessary evil of supporting multiple inheritance. PHP does not have MI and thus there was never a need for such a contrived scope resolution operator when something like Java's super would have sufficed. I can recognize that its usage dates back to the very beginning of PHP OOP, and it would be problematic to change the :: operator with all the existing code out there. Why can't we choose a new operator for pure static calls and get on with it ? It sounds like that would allow same-named static methods without ambiguity, while allowing the :: operator to continue as-is. [2013-04-21 18:57:01] dmittner at llnw dot com @ni...@php.net: While what you write is all technically correct, I think it comes down to this being the problem: :: is not a static access operator, it's a scope resolution operator. It calls a method (or accesses a property) in a certain scope. Conceptually that one operator is trying to do too much. That certain scope it's trying to use isn't chosen by the programmer; it's chosen by the context; by where it's being used. That's presumptuous and an unnecessary limitation. :: is (AFAIK) the only way to access specifically static resources in one context, but then is also used to reference the resources of special names in other contexts. Clearly people want to be able to call the same method name in both an object and static scope. It's the same reason people like function overloading: they have logic that accomplishes the same goal but done differently--this time based on scope. And we'd rather not dirty our code with resource names named differently just to identify scope. If the :: operator can't consistently serve this purpose because it's also having to accommodate parent and other special names, then maybe we just need a new
Bug #40837 [Com]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837edit=1 ID: 40837 Comment by: dmittner at llnw dot com Reported by:nick dot telford at gmail dot com Summary:static and non-static functions can't have the same name Status: Not a bug Type: Bug Package:Class/Object related Operating System: Irrelevant PHP Version:5.2.1 Block user comment: N Private report: N New Comment: Well, given the lack of similar support in other languages I can see this is an uphill battle not worth a long fight, so I'll leave with this departing thought (plus I doubt this is a proper place to debate merits of functionality changes): When I looked up this similar issue on other languages, I found people asking about it for Java and C#, and the responses fundamentally came down to the same thing: the compiler doesn't understand it. But it was clear that this is something people want in many languages, and I'd put forth that all of them doing it poorly isn't justification not to lead the charge to building a better convention. Fact is, static scope exists separate of instance scope for a reason. And if we're accepting that reason as enough to support both scopes' existence to begin with, why isn't that reason enough to take the next logical step and support resource signatures of the same name for each? Obviously using :: is out of the question and similar limitations in other languages is likely why it's not possible in them, but if we have new operators specifically to separate these, why not do it? Maybe it would put pressure on other languages to add similar support. The only remaining argument against it I could see would be one of code cleanliness and possible confusion having two methods with the same signature, but I'd have to dismiss that as minor (especially compared to overloading signatures in other languages) when there's a clear static presence on the method and the new operator on any calls to it. And with that, good day and happy programming. Previous Comments: [2013-04-21 22:34:18] ni...@php.net @dmittner: :: is not a static access operator, it's a scope resolution operator. It calls a method (or accesses a property) in a certain scope. Conceptually that one operator is trying to do too much. That certain scope it's trying to use isn't chosen by the programmer; it's chosen by the context; by where it's being used. That's presumptuous and an unnecessary limitation. Maybe I didn't phrase that well enough. By in a certain scope I meant the class before the :: operator. In Foo::bar() the bar() method is called in the Foo scope. So, as you can see the scope *is* chosen by the programmer and no presumption takes place. :: is (AFAIK) the only way to access specifically static resources in one context, but then is also used to reference the resources of special names in other contexts. Again, this might be a misunderstanding. The scope-resolution behavior is *not* restricted to special names. It's not just about parent::foo() [and self::foo() and static::foo()], I just used that as an example as it is the most commonly used. You can do a scope-resolution call on any class in the inheritance hierarchy (e.g. a grandparent). Actually right now you could even do the call to using a scope that is outside the hierarchy, but thankfully we'll be removing that anti-feature in the next version. What we could obviously do - as you suggest - is strictly decouple scoped static method calls and scoped non-static method calls, by having a Foo::bar() syntax and a Foo-bar() syntax (e.g. parent-bar()). In my eyes that's a bad idea. We'd be adding a lot of new complexity (by making static methods *actually* different and not just a modifier of normal methods) only for the very small gain of having statics and non-statics of the same name. By the way, I just looked at a few other languages and it seems like nearly all went the same way as PHP. C++ doesn't allow it, C# doesn't allow it, Java doesn't allow it. Python doesn't really have statics, but it has the @staticmethod decorator and with that it's obviously not allowed either. The only language I looked at and which *does* support this is Ruby. So, I really don't see a solid case for this feature request. [2013-04-21 21:47:20] billco at fnarg dot com My thoughts echo those of dmittner, while I think we all acknowledge the need for parent::method() functionality, I don't see why that small detail should invalidate this popular feature request. This seems like a limitation borrowed from C++, where it was a necessary evil of supporting multiple inheritance. PHP does not have MI and thus there was never a need for such a contrived scope
Bug #40837 [Com]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837edit=1 ID: 40837 Comment by: capitaine dot gloumi at gmail dot com Reported by:nick dot telford at gmail dot com Summary:static and non-static functions can't have the same name Status: Not a bug Type: Bug Package:Class/Object related Operating System: Irrelevant PHP Version:5.2.1 Block user comment: N Private report: N New Comment: The backward compatibility should set to deprecated any static call of object method, and use it IF NO static method with the same name exist. I use static method and object method with same name in lot of paterns, it's useful in lot of case. Previous Comments: [2012-11-19 03:27:35] ahar...@php.net If a class is namespaced, by definition it isn't PHP 4 compatible. [2012-11-15 23:23:31] jpmarois at hotmail dot com ahar...@php.net: Sure, go Microsoft's way and move forward by staying behind for the sake of compatibility. Please explain why, As of PHP 5.3.3, methods with the same name as the last element of a namespaced class name will no longer be treated as constructor.. If PHP wont even initialize a compatible PHP 4 class anymore, how is it relevant to preserve instance methods being called statically? [2012-09-11 01:59:54] ahar...@php.net It breaks compatibility with any PHP 4 compatible code that uses static method calls. That's (obviously) less important than it once was, but there's still plenty of legacy code out there. [2012-09-10 15:29:23] mac at macnewbold dot com ahar...@php.net : What would the impacts be of deprecating static calls to non-static methods? They would seem to not make much sense, since any uses of $this inside the method (which would be pretty typical since it is a non-static method) would fail with Fatal error: Using $this when not in object context. What is the value of being able to attempt a static call on a non-static method? [2012-09-10 03:00:14] ahar...@php.net For the record, there's no way this can be implemented as it stands: for backward compatibility reasons, instance methods can be called statically, so the name has to be distinct to disambiguate between static and instance methods. The call type is not enough. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=40837 -- Edit this bug report at https://bugs.php.net/bug.php?id=40837edit=1
Bug #40837 [Com]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837edit=1 ID: 40837 Comment by: jpmarois at hotmail dot com Reported by:nick dot telford at gmail dot com Summary:static and non-static functions can't have the same name Status: Not a bug Type: Bug Package:Class/Object related Operating System: Irrelevant PHP Version:5.2.1 Block user comment: N Private report: N New Comment: ahar...@php.net: Sure, go Microsoft's way and move forward by staying behind for the sake of compatibility. Please explain why, As of PHP 5.3.3, methods with the same name as the last element of a namespaced class name will no longer be treated as constructor.. If PHP wont even initialize a compatible PHP 4 class anymore, how is it relevant to preserve instance methods being called statically? Previous Comments: [2012-09-11 01:59:54] ahar...@php.net It breaks compatibility with any PHP 4 compatible code that uses static method calls. That's (obviously) less important than it once was, but there's still plenty of legacy code out there. [2012-09-10 15:29:23] mac at macnewbold dot com ahar...@php.net : What would the impacts be of deprecating static calls to non-static methods? They would seem to not make much sense, since any uses of $this inside the method (which would be pretty typical since it is a non-static method) would fail with Fatal error: Using $this when not in object context. What is the value of being able to attempt a static call on a non-static method? [2012-09-10 03:00:14] ahar...@php.net For the record, there's no way this can be implemented as it stands: for backward compatibility reasons, instance methods can be called statically, so the name has to be distinct to disambiguate between static and instance methods. The call type is not enough. [2012-09-07 22:33:55] accounts dot php at nickawilliams dot com I also support this proposal. On numerous occasions throughout my career writing PHP I have found a need for this. While there are workarounds that work, they are all fairly verbose, convoluted, and/or difficult to follow. Please consider reopening this! [2012-08-04 00:46:35] billco at fnarg dot com Same here! This is a very useful pattern in other languages, where the same method name can be used in both static and non-static contexts. For example, a search() method in static context could create a new result object, while the non-static form would search within an existing result set. While it is possible to mimic this sort of behaviour by first creating a blank object, it leads to dual-purpose methods (a big if statement), resulting in messy, unmaintainable code. Why arbitrarily force developers to violate good OOP practices ? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=40837 -- Edit this bug report at https://bugs.php.net/bug.php?id=40837edit=1
Bug #40837 [Com]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837edit=1 ID: 40837 Comment by: mac at macnewbold dot com Reported by:nick dot telford at gmail dot com Summary:static and non-static functions can't have the same name Status: Not a bug Type: Bug Package:Class/Object related Operating System: Irrelevant PHP Version:5.2.1 Block user comment: N Private report: N New Comment: ahar...@php.net : What would the impacts be of deprecating static calls to non-static methods? They would seem to not make much sense, since any uses of $this inside the method (which would be pretty typical since it is a non-static method) would fail with Fatal error: Using $this when not in object context. What is the value of being able to attempt a static call on a non-static method? Previous Comments: [2012-09-10 03:00:14] ahar...@php.net For the record, there's no way this can be implemented as it stands: for backward compatibility reasons, instance methods can be called statically, so the name has to be distinct to disambiguate between static and instance methods. The call type is not enough. [2012-09-07 22:33:55] accounts dot php at nickawilliams dot com I also support this proposal. On numerous occasions throughout my career writing PHP I have found a need for this. While there are workarounds that work, they are all fairly verbose, convoluted, and/or difficult to follow. Please consider reopening this! [2012-08-04 00:46:35] billco at fnarg dot com Same here! This is a very useful pattern in other languages, where the same method name can be used in both static and non-static contexts. For example, a search() method in static context could create a new result object, while the non-static form would search within an existing result set. While it is possible to mimic this sort of behaviour by first creating a blank object, it leads to dual-purpose methods (a big if statement), resulting in messy, unmaintainable code. Why arbitrarily force developers to violate good OOP practices ? [2012-06-28 08:15:27] info at renemaas dot de Yeah this would be really helpful. I hope anybody of the PHP team will implement this kind of stupid feature. If not them please provide a cool solution for using static and non-static functions. [2011-12-21 18:26:14] mac at macnewbold dot com I agree with martijntje and nick.telford - the static function and normal function of the same name shouldn't have any conflict, and it would be extremely helpful to be able to define the same function for use both statically and non-statically. In the meantime, I'm going to try using __call() and __callStatic() to pretend like this feature actually exists. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=40837 -- Edit this bug report at https://bugs.php.net/bug.php?id=40837edit=1
Bug #40837 [Com]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837edit=1 ID: 40837 Comment by: accounts dot php at nickawilliams dot com Reported by:nick dot telford at gmail dot com Summary:static and non-static functions can't have the same name Status: Not a bug Type: Bug Package:Class/Object related Operating System: Irrelevant PHP Version:5.2.1 Block user comment: N Private report: N New Comment: I also support this proposal. On numerous occasions throughout my career writing PHP I have found a need for this. While there are workarounds that work, they are all fairly verbose, convoluted, and/or difficult to follow. Please consider reopening this! Previous Comments: [2012-08-04 00:46:35] billco at fnarg dot com Same here! This is a very useful pattern in other languages, where the same method name can be used in both static and non-static contexts. For example, a search() method in static context could create a new result object, while the non-static form would search within an existing result set. While it is possible to mimic this sort of behaviour by first creating a blank object, it leads to dual-purpose methods (a big if statement), resulting in messy, unmaintainable code. Why arbitrarily force developers to violate good OOP practices ? [2012-06-28 08:15:27] info at renemaas dot de Yeah this would be really helpful. I hope anybody of the PHP team will implement this kind of stupid feature. If not them please provide a cool solution for using static and non-static functions. [2011-12-21 18:26:14] mac at macnewbold dot com I agree with martijntje and nick.telford - the static function and normal function of the same name shouldn't have any conflict, and it would be extremely helpful to be able to define the same function for use both statically and non-statically. In the meantime, I'm going to try using __call() and __callStatic() to pretend like this feature actually exists. [2011-11-26 22:17:42] martijntje at martijnotto dot nl I have no idea why this bug is closed as 'bogus'. Just because the documentation states it is a certain way does not mean that it is right. I, for one, believe that it should be possible to create both a static and a member function with the same name. There would never be any confusion as to which function should be called due to the difference of using the :: or - operator. [2007-03-16 17:40:02] he...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php . The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=40837 -- Edit this bug report at https://bugs.php.net/bug.php?id=40837edit=1
Bug #40837 [Com]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837edit=1
ID: 40837
Comment by: billco at fnarg dot com
Reported by:nick dot telford at gmail dot com
Summary:static and non-static functions can't have the same
name
Status: Not a bug
Type: Bug
Package:Class/Object related
Operating System: Irrelevant
PHP Version:5.2.1
Block user comment: N
Private report: N
New Comment:
Same here! This is a very useful pattern in other languages, where the same
method name can be used in both static and non-static contexts.
For example, a search() method in static context could create a new result
object, while the non-static form would search within an existing result set.
While it is possible to mimic this sort of behaviour by first creating a
blank object, it leads to dual-purpose methods (a big if statement),
resulting in messy, unmaintainable code. Why arbitrarily force developers to
violate good OOP practices ?
Previous Comments:
[2012-06-28 08:15:27] info at renemaas dot de
Yeah this would be really helpful. I hope anybody of the PHP team will
implement
this kind of stupid feature. If not them please provide a cool solution for
using static and non-static functions.
[2011-12-21 18:26:14] mac at macnewbold dot com
I agree with martijntje and nick.telford - the static function and normal
function of the same name shouldn't have any conflict, and it would be
extremely helpful to be able to define the same function for use both
statically and non-statically.
In the meantime, I'm going to try using __call() and __callStatic() to pretend
like this feature actually exists.
[2011-11-26 22:17:42] martijntje at martijnotto dot nl
I have no idea why this bug is closed as 'bogus'. Just because the
documentation
states it is a certain way does not mean that it is right.
I, for one, believe that it should be possible to create both a static and a
member function with the same name. There would never be any confusion as to
which function should be called due to the difference of using the :: or -
operator.
[2007-03-16 17:40:02] he...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
.
[2007-03-16 16:44:17] nick dot telford at gmail dot com
Description:
When declaring two functions in a class (methods) non-static and static
functions may not use the same names.
While I understand this, this is essentially wrong since static methods and
non-static methods are entirely different.
This also leads me on to another bug/feature suggestion I'm about to file about
not being able to overload static attributes with __set/__get.
Reproduce code:
---
class Example {
public static function test() {}
public function test() {}
}
$example = new Example();
$example-test();
Example::test();
Expected result:
No errors, all methods called correctly.
Actual result:
--
PHP errors with: Fatal error: Cannot redeclare Example::test()
--
Edit this bug report at https://bugs.php.net/bug.php?id=40837edit=1
Bug #40837 [Com]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837edit=1
ID: 40837
Comment by: info at renemaas dot de
Reported by:nick dot telford at gmail dot com
Summary:static and non-static functions can't have the same
name
Status: Not a bug
Type: Bug
Package:Class/Object related
Operating System: Irrelevant
PHP Version:5.2.1
Block user comment: N
Private report: N
New Comment:
Yeah this would be really helpful. I hope anybody of the PHP team will
implement
this kind of stupid feature. If not them please provide a cool solution for
using static and non-static functions.
Previous Comments:
[2011-12-21 18:26:14] mac at macnewbold dot com
I agree with martijntje and nick.telford - the static function and normal
function of the same name shouldn't have any conflict, and it would be
extremely helpful to be able to define the same function for use both
statically and non-statically.
In the meantime, I'm going to try using __call() and __callStatic() to pretend
like this feature actually exists.
[2011-11-26 22:17:42] martijntje at martijnotto dot nl
I have no idea why this bug is closed as 'bogus'. Just because the
documentation
states it is a certain way does not mean that it is right.
I, for one, believe that it should be possible to create both a static and a
member function with the same name. There would never be any confusion as to
which function should be called due to the difference of using the :: or -
operator.
[2007-03-16 17:40:02] he...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
.
[2007-03-16 16:44:17] nick dot telford at gmail dot com
Description:
When declaring two functions in a class (methods) non-static and static
functions may not use the same names.
While I understand this, this is essentially wrong since static methods and
non-static methods are entirely different.
This also leads me on to another bug/feature suggestion I'm about to file about
not being able to overload static attributes with __set/__get.
Reproduce code:
---
class Example {
public static function test() {}
public function test() {}
}
$example = new Example();
$example-test();
Example::test();
Expected result:
No errors, all methods called correctly.
Actual result:
--
PHP errors with: Fatal error: Cannot redeclare Example::test()
--
Edit this bug report at https://bugs.php.net/bug.php?id=40837edit=1
Bug #40837 [Com]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837edit=1
ID: 40837
Comment by: mac at macnewbold dot com
Reported by:nick dot telford at gmail dot com
Summary:static and non-static functions can't have the same
name
Status: Bogus
Type: Bug
Package:Class/Object related
Operating System: Irrelevant
PHP Version:5.2.1
Block user comment: N
Private report: N
New Comment:
I agree with martijntje and nick.telford - the static function and normal
function of the same name shouldn't have any conflict, and it would be
extremely helpful to be able to define the same function for use both
statically and non-statically.
In the meantime, I'm going to try using __call() and __callStatic() to pretend
like this feature actually exists.
Previous Comments:
[2011-11-26 22:17:42] martijntje at martijnotto dot nl
I have no idea why this bug is closed as 'bogus'. Just because the
documentation
states it is a certain way does not mean that it is right.
I, for one, believe that it should be possible to create both a static and a
member function with the same name. There would never be any confusion as to
which function should be called due to the difference of using the :: or -
operator.
[2007-03-16 17:40:02] he...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
.
[2007-03-16 16:44:17] nick dot telford at gmail dot com
Description:
When declaring two functions in a class (methods) non-static and static
functions may not use the same names.
While I understand this, this is essentially wrong since static methods and
non-static methods are entirely different.
This also leads me on to another bug/feature suggestion I'm about to file about
not being able to overload static attributes with __set/__get.
Reproduce code:
---
class Example {
public static function test() {}
public function test() {}
}
$example = new Example();
$example-test();
Example::test();
Expected result:
No errors, all methods called correctly.
Actual result:
--
PHP errors with: Fatal error: Cannot redeclare Example::test()
--
Edit this bug report at https://bugs.php.net/bug.php?id=40837edit=1
Bug #40837 [Com]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837edit=1
ID: 40837
Comment by: martijntje at martijnotto dot nl
Reported by:nick dot telford at gmail dot com
Summary:static and non-static functions can't have the same
name
Status: Bogus
Type: Bug
Package:Class/Object related
Operating System: Irrelevant
PHP Version:5.2.1
Block user comment: N
Private report: N
New Comment:
I have no idea why this bug is closed as 'bogus'. Just because the
documentation
states it is a certain way does not mean that it is right.
I, for one, believe that it should be possible to create both a static and a
member function with the same name. There would never be any confusion as to
which function should be called due to the difference of using the :: or -
operator.
Previous Comments:
[2007-03-16 17:40:02] he...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
.
[2007-03-16 16:44:17] nick dot telford at gmail dot com
Description:
When declaring two functions in a class (methods) non-static and static
functions may not use the same names.
While I understand this, this is essentially wrong since static methods and
non-static methods are entirely different.
This also leads me on to another bug/feature suggestion I'm about to file about
not being able to overload static attributes with __set/__get.
Reproduce code:
---
class Example {
public static function test() {}
public function test() {}
}
$example = new Example();
$example-test();
Example::test();
Expected result:
No errors, all methods called correctly.
Actual result:
--
PHP errors with: Fatal error: Cannot redeclare Example::test()
--
Edit this bug report at https://bugs.php.net/bug.php?id=40837edit=1
