www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Overloading static methods

reply Jacob Carlborg <doob me.com> writes:
I just got and idea, what about allowing to overload methods based on if 
they're static or not. This would allow the following code:

class Foo
{
     void bar () { writeln("bar"); }	
     static void bar () { writeln("static bar"); }
}

Foo.bar; // would print "static bar"
auto foo = new Foo;
foo.bar; // would print "bar"

When inside a class/struct there would be an ambiguity if both a static 
and a non-static method is present. To solve this one would always need 
to prefix the static method call with the class/struct name, i.e. 
"Foo.bar()". To call the instance method I see two options, either the 
method call needs to be prefixed with "this", i.e. "this.bar()" or all 
calls that are not prefixed would always call the instance method.

Thoughts?

-- 
/Jacob Carlborg
Aug 29 2011
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:j3fi1u$1uge$1 digitalmars.com...
I just got and idea, what about allowing to overload methods based on if 
they're static or not.
From my list of 'Andrei' bugs: http://d.puremagic.com/issues/show_bug.cgi?id=3345 It sounds like a good idea, but what are the real use cases and what are the corner cases?
Aug 29 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-08-29 16:10, Daniel Murphy wrote:
 "Jacob Carlborg"<doob me.com>  wrote in message
 news:j3fi1u$1uge$1 digitalmars.com...
 I just got and idea, what about allowing to overload methods based on if
 they're static or not.
From my list of 'Andrei' bugs: http://d.puremagic.com/issues/show_bug.cgi?id=3345 It sounds like a good idea, but what are the real use cases and what are the corner cases?
In my serialization library, Orange, I want to have a "reset" method that is both static and non-static. The static method would reset some static variables while the non-static method would reset the instance variables. Another use case is to have a static and non-static opDispatch at the same time. I've been playing around with the idea of having something similar to Ruby on Rails' activerecord implemented in D. In activerecord you can do something like this: p = Person.find_by_name("Joe") name = p.name Both "find_by_name" and "name" are implemented using "method_missing" (Ruby's opDispatch). In D, this would require both a static and a non-static opDispatch. I've already mentioned the issue when inside a class/struct and a solution, don't know if that counts as a corner case. That's the only issue I can think of so far. -- /Jacob Carlborg
Aug 29 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 29 Aug 2011 10:25:18 -0400, Jacob Carlborg <doob me.com> wrote:

 On 2011-08-29 16:10, Daniel Murphy wrote:
 "Jacob Carlborg"<doob me.com>  wrote in message
 news:j3fi1u$1uge$1 digitalmars.com...
 I just got and idea, what about allowing to overload methods based on  
 if
 they're static or not.
From my list of 'Andrei' bugs: http://d.puremagic.com/issues/show_bug.cgi?id=3345 It sounds like a good idea, but what are the real use cases and what are the corner cases?
In my serialization library, Orange, I want to have a "reset" method that is both static and non-static. The static method would reset some static variables while the non-static method would reset the instance variables. Another use case is to have a static and non-static opDispatch at the same time. I've been playing around with the idea of having something similar to Ruby on Rails' activerecord implemented in D. In activerecord you can do something like this: p = Person.find_by_name("Joe") name = p.name Both "find_by_name" and "name" are implemented using "method_missing" (Ruby's opDispatch). In D, this would require both a static and a non-static opDispatch.
opDispatch is a much more convincing use case than just some random function name. But one function name can be solved. i.e. opStaticDispatch. I had a similar issue with D a long long time ago, but I since fixed the problem by just renaming one of the functions. My opinion is that static methods should *not* be callable from an instance, you should need typeof(instance).staticMethod. The current allowance is misleading. This should solve some of the issues, but of course, you'd need to allow overloading of the method name in static and non-static forms. -Steve
Aug 29 2011
next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.v0zckubyeav7ka localhost.localdomain...
 My opinion is that static methods should *not* be callable from an 
 instance, you should need typeof(instance).staticMethod.  The current 
 allowance is misleading.

 This should solve some of the issues, but of course, you'd need to allow 
 overloading of the method name in static and non-static forms.

 -Steve
I like this idea. Is there a bugzilla entry for it? With this disallowing overloading static vs non-static would be a pointless limitation.
Aug 29 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 29 Aug 2011 10:59:22 -0400, Daniel Murphy  
<yebblies nospamgmail.com> wrote:

 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.v0zckubyeav7ka localhost.localdomain...
 My opinion is that static methods should *not* be callable from an
 instance, you should need typeof(instance).staticMethod.  The current
 allowance is misleading.

 This should solve some of the issues, but of course, you'd need to allow
 overloading of the method name in static and non-static forms.

 -Steve
I like this idea. Is there a bugzilla entry for it?
I'll add it, if it's not already there. -Steve
Aug 30 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 30 Aug 2011 07:53:15 -0400, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 On Mon, 29 Aug 2011 10:59:22 -0400, Daniel Murphy  
 <yebblies nospamgmail.com> wrote:

 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.v0zckubyeav7ka localhost.localdomain...
 My opinion is that static methods should *not* be callable from an
 instance, you should need typeof(instance).staticMethod.  The current
 allowance is misleading.

 This should solve some of the issues, but of course, you'd need to  
 allow
 overloading of the method name in static and non-static forms.

 -Steve
I like this idea. Is there a bugzilla entry for it?
I'll add it, if it's not already there.
http://d.puremagic.com/issues/show_bug.cgi?id=6579 -Steve
Aug 30 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-08-30 14:34, Steven Schveighoffer wrote:
 On Tue, 30 Aug 2011 07:53:15 -0400, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:

 On Mon, 29 Aug 2011 10:59:22 -0400, Daniel Murphy
 <yebblies nospamgmail.com> wrote:

 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.v0zckubyeav7ka localhost.localdomain...
 My opinion is that static methods should *not* be callable from an
 instance, you should need typeof(instance).staticMethod. The current
 allowance is misleading.

 This should solve some of the issues, but of course, you'd need to
 allow
 overloading of the method name in static and non-static forms.

 -Steve
I like this idea. Is there a bugzilla entry for it?
I'll add it, if it's not already there.
http://d.puremagic.com/issues/show_bug.cgi?id=6579 -Steve
As Daniel answered previously in this thread, this has already been reported: http://d.puremagic.com/issues/show_bug.cgi?id=3345 -- /Jacob Carlborg
Aug 30 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 30 Aug 2011 10:19:27 -0400, Jacob Carlborg <doob me.com> wrote:

 On 2011-08-30 14:34, Steven Schveighoffer wrote:
 On Tue, 30 Aug 2011 07:53:15 -0400, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:

 On Mon, 29 Aug 2011 10:59:22 -0400, Daniel Murphy
 <yebblies nospamgmail.com> wrote:

 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.v0zckubyeav7ka localhost.localdomain...
 My opinion is that static methods should *not* be callable from an
 instance, you should need typeof(instance).staticMethod. The current
 allowance is misleading.

 This should solve some of the issues, but of course, you'd need to
 allow
 overloading of the method name in static and non-static forms.

 -Steve
I like this idea. Is there a bugzilla entry for it?
I'll add it, if it's not already there.
http://d.puremagic.com/issues/show_bug.cgi?id=6579 -Steve
As Daniel answered previously in this thread, this has already been reported: http://d.puremagic.com/issues/show_bug.cgi?id=3345
It's different. 3345 is asking to allow overloading of static and instance methods with the same signature. The new bug is asking to *require* using the type when accessing static methods/fields. You might notice in the bug report that I mention this "paves the way for bug 3345" :) -Steve
Aug 30 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-08-30 16:28, Steven Schveighoffer wrote:
 It's different. 3345 is asking to allow overloading of static and
 instance methods with the same signature. The new bug is asking to
 *require* using the type when accessing static methods/fields.

 You might notice in the bug report that I mention this "paves the way
 for bug 3345" :)

 -Steve
Aha, I see, thanks. -- /Jacob Carlborg
Aug 30 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/30/11 7:34 AM, Steven Schveighoffer wrote:
 On Tue, 30 Aug 2011 07:53:15 -0400, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:

 On Mon, 29 Aug 2011 10:59:22 -0400, Daniel Murphy
 <yebblies nospamgmail.com> wrote:

 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.v0zckubyeav7ka localhost.localdomain...
 My opinion is that static methods should *not* be callable from an
 instance, you should need typeof(instance).staticMethod. The current
 allowance is misleading.

 This should solve some of the issues, but of course, you'd need to
 allow
 overloading of the method name in static and non-static forms.

 -Steve
I like this idea. Is there a bugzilla entry for it?
I'll add it, if it's not already there.
http://d.puremagic.com/issues/show_bug.cgi?id=6579 -Steve
I'll note that calls of static methods for instances has been a boon to generic programming in C++. People could call a method and it was up to the implementation whether it was static or not. We don't have as big a problem in D due to introspection. I fear, however, that we'll need to add static if (...) obj.method(); else typeof(obj).method(); I don't see an improvement. Andrei
Aug 30 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 30 Aug 2011 11:38:54 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 8/30/11 7:34 AM, Steven Schveighoffer wrote:
 On Tue, 30 Aug 2011 07:53:15 -0400, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:

 On Mon, 29 Aug 2011 10:59:22 -0400, Daniel Murphy
 <yebblies nospamgmail.com> wrote:

 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.v0zckubyeav7ka localhost.localdomain...
 My opinion is that static methods should *not* be callable from an
 instance, you should need typeof(instance).staticMethod. The current
 allowance is misleading.

 This should solve some of the issues, but of course, you'd need to
 allow
 overloading of the method name in static and non-static forms.

 -Steve
I like this idea. Is there a bugzilla entry for it?
I'll add it, if it's not already there.
http://d.puremagic.com/issues/show_bug.cgi?id=6579 -Steve
I'll note that calls of static methods for instances has been a boon to generic programming in C++. People could call a method and it was up to the implementation whether it was static or not.
Yes, you are right. But there is an ugly flip side to that coin. The issue is, when someone designs a static method to be called on an *instance*, it makes sense. But when someone designs a static method to be called on the *type* (which is predominantly how I write them), it often does not make any sense to call it on the instance. Yet, the compiler still compiles. An example I gave in the bug report just now is File. Imagine you have a File struct, and want to have an open method: struct File { static File open(string fname); } However, now this is valid code: File f; f.open(fname); // does not do what you think it does... I agree there are ways to design around this, but the fact that the intentions of the designer are not upheld (and cannot be) by the compiler is troubling to me. I *named* the function expecting it to be called a certain way, yet confusion abounds when called some way I didn't intend or anticipate. One seldom thinks of the instance-calling-static mechanism when designing a static method that is meant to be called with the type.
 We don't have as big a problem in D due to introspection. I fear,  
 however, that we'll need to add static if (...) obj.method(); else  
 typeof(obj).method();

 I don't see an improvement.
In terms of generic programming, you have a good point. I don't see a good way around this without altering syntax. Perhaps we could do something like this (a la recently added disable this): struct File { static File open(string fname); disable open; // disable calling from an instance } Yuck... nevermind :) -Steve
Aug 30 2011
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 30 Aug 2011 11:58:20 -0400, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 On Tue, 30 Aug 2011 11:38:54 -0400, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 On 8/30/11 7:34 AM, Steven Schveighoffer wrote:
 We don't have as big a problem in D due to introspection. I fear,  
 however, that we'll need to add static if (...) obj.method(); else  
 typeof(obj).method();

 I don't see an improvement.
In terms of generic programming, you have a good point. I don't see a good way around this without altering syntax. Perhaps we could do something like this (a la recently added disable this): struct File { static File open(string fname); disable open; // disable calling from an instance } Yuck... nevermind :)
Hm... this might be workable. Disallow calling static method from instance unless requested by the author: struct S1 { static void foo(); } struct S2 { static void foo(); alias foo this.foo; } S1 s1; S2 s2; s1.foo(); // error s2.foo(); // ok -Steve
Aug 30 2011
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 struct S2
 {
    static void foo();
    alias foo this.foo;
 }
or alias typeof(this).foo foo;
Aug 30 2011
prev sibling parent reply mta`chrono <chrono mta-international.net> writes:
Quote: Steven Schveighoffer
 An example I gave in the bug report just now is File.  Imagine you have
 a File struct, and want to have an open method:
 
 struct File
 {
    static File open(string fname);
 }
 
 However, now this is valid code:
 
 File f; // <-------- here's the problem!
 f.open(fname);  // does not do what you think it does...
 
Yes, but why is he able to get an instance of File? The Designer of "File" should have rather used a class and disallow to create any instance of it. ( disable this) If instantiation should be only possible through a static function, then implement a private constructor or disable it. Quote: Andrei Alexandrescu
 I'll note that calls of static methods for instances has been a boon to
 generic programming in C++. People could call a method and it was up to
 the implementation whether it was static or not.
This is a D feature. It's up to the designer to implement it static or non-static way. You don't have to care about, just call it.
Sep 24 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 24 Sep 2011 16:26:34 -0400, mta`chrono  
<chrono mta-international.net> wrote:

 Quote: Steven Schveighoffer
 An example I gave in the bug report just now is File.  Imagine you have
 a File struct, and want to have an open method:

 struct File
 {
    static File open(string fname);
 }

 However, now this is valid code:

 File f; // <-------- here's the problem!
 f.open(fname);  // does not do what you think it does...
Yes, but why is he able to get an instance of File? The Designer of "File" should have rather used a class and disallow to create any instance of it. ( disable this)
I think this post predates disable this (not sure), but in any case, that is not the issue: File f = File.open("blah.txt"); f.open("blah2.txt"); -Steve
Sep 26 2011
prev sibling next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 29-08-2011 16:44, Steven Schveighoffer wrote:
 My opinion is that static methods should *not* be callable from an
 instance, you should need typeof(instance).staticMethod.  The current
 allowance is misleading.
+1. - Alex
Aug 29 2011
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, August 29, 2011 07:44 Steven Schveighoffer wrote:
 My opinion is that static methods should *not* be callable from an
 instance, you should need typeof(instance).staticMethod. The current
 allowance is misleading.
it too, but I've always thought that it was a bad idea in all of those languages. I don't see a problem being able to call a static method inside of its class without giving the class name (if you had both a static and non- static method with the same name, then you could simply require that either the type name or this be use), but it strikes me as very lax to allow a static method to be called with an instance. That's definitely one of the little things that I'd love to see changed. It's not the end of the world if it isn't, but I see no cons to changing it other than the possibility of breaking code (which was arguably bad code to begin with). - Jonathan M Davis
Aug 29 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


 it too, but I've always thought that it was a bad idea in all of those 
 languages.
 ...
 but it strikes me as very lax to allow a static 
 method to be called with an instance. That's definitely one of the little 
 things that I'd love to see changed.
I agree. I don't understand the rationale for allowing the access of static fields though the instance name. Requiring the class/struct name also makes the look of this code more meaningful: const struct Foo { int x; static int y; static void incy() { y++; } } void main() { Foo f = Foo(5); f.y++; // no error here f.incy(); // no error here } Bye, bearophile
Aug 29 2011
prev sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 29-08-2011 19:47, Jonathan M Davis wrote:
 On Monday, August 29, 2011 07:44 Steven Schveighoffer wrote:
 My opinion is that static methods should *not* be callable from an
 instance, you should need typeof(instance).staticMethod. The current
 allowance is misleading.
it too, but I've always thought that it was a bad idea in all of those languages. I don't see a problem being able to call a static method inside of its class without giving the class name (if you had both a static and non- static method with the same name, then you could simply require that either the type name or this be use), but it strikes me as very lax to allow a static method to be called with an instance. That's definitely one of the little things that I'd love to see changed. It's not the end of the world if it isn't, but I see no cons to changing it other than the possibility of breaking code (which was arguably bad code to begin with). - Jonathan M Davis
no Java expert). Overall, I think this entire "call static method on instance" deal comes from C++. - Alex
Aug 29 2011
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, August 29, 2011 12:53 Alex Rønne Petersen wrote:
 On 29-08-2011 19:47, Jonathan M Davis wrote:
 On Monday, August 29, 2011 07:44 Steven Schveighoffer wrote:
 My opinion is that static methods should *not* be callable from an
 instance, you should need typeof(instance).staticMethod. The current
 allowance is misleading.
allow it too, but I've always thought that it was a bad idea in all of those languages. I don't see a problem being able to call a static method inside of its class without giving the class name (if you had both a static and non- static method with the same name, then you could simply require that either the type name or this be use), but it strikes me as very lax to allow a static method to be called with an instance. That's definitely one of the little things that I'd love to see changed. It's not the end of the world if it isn't, but I see no cons to changing it other than the possibility of breaking code (which was arguably bad code to begin with). - Jonathan M Davis
no Java expert). Overall, I think this entire "call static method on instance" deal comes from C++.
but I'm 99.99% sure that Java allows it. I definitely remember being irritated by it in Java. - Jonathan M Davis
Aug 29 2011
parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 29.08.2011, 22:24 Uhr, schrieb Jonathan M Davis <jmdavisProg gmx.com>=
:

 On Monday, August 29, 2011 12:53 Alex R=C3=B8nne Petersen wrote:
 On 29-08-2011 19:47, Jonathan M Davis wrote:
 On Monday, August 29, 2011 07:44 Steven Schveighoffer wrote:
 My opinion is that static methods should *not* be callable from an=
 instance, you should need typeof(instance).staticMethod. The curre=
nt
 allowance is misleading.
=
 all
 allow it too, but I've always thought that it was a bad idea in all=
of
 those languages. I don't see a problem being able to call a static
 method inside of its class without giving the class name (if you ha=
d
 both a static and non- static method with the same name, then you  =
 could
 simply require that either the type name or this be use), but it  =
 strikes
 me as very lax to allow a static method to be called with an instan=
ce.
 That's definitely one of the little things that I'd love to see  =
 changed.
 It's not the end of the world if it isn't, but I see no cons to  =
 changing
 it other than the possibility of breaking code (which was arguably =
bad
 code to begin with).

 - Jonathan M Davis
nly
 no Java expert). Overall, I think this entire "call static method on
 instance" deal comes from C++.
ut =
 that,
 but I'm 99.99% sure that Java allows it. I definitely remember being  =
 irritated
 by it in Java.

 - Jonathan M Davis
Java allows it, but gives a warning and auto-correct option to use the = class reference instead, in Eclipse. That probably means that there is n= o = justifiable use-case for it.
Aug 30 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/30/11 7:40 AM, Marco Leise wrote:
 Am 29.08.2011, 22:24 Uhr, schrieb Jonathan M Davis <jmdavisProg gmx.com>:

 On Monday, August 29, 2011 12:53 Alex Rønne Petersen wrote:
 On 29-08-2011 19:47, Jonathan M Davis wrote:
 On Monday, August 29, 2011 07:44 Steven Schveighoffer wrote:
 My opinion is that static methods should *not* be callable from an
 instance, you should need typeof(instance).staticMethod. The current
 allowance is misleading.
all
 allow it too, but I've always thought that it was a bad idea in all of
 those languages. I don't see a problem being able to call a static
 method inside of its class without giving the class name (if you had
 both a static and non- static method with the same name, then you
could
 simply require that either the type name or this be use), but it
strikes
 me as very lax to allow a static method to be called with an instance.
 That's definitely one of the little things that I'd love to see
changed.
 It's not the end of the world if it isn't, but I see no cons to
changing
 it other than the possibility of breaking code (which was arguably bad
 code to begin with).

 - Jonathan M Davis
no Java expert). Overall, I think this entire "call static method on instance" deal comes from C++.
about that, but I'm 99.99% sure that Java allows it. I definitely remember being irritated by it in Java. - Jonathan M Davis
Java allows it, but gives a warning and auto-correct option to use the class reference instead, in Eclipse. That probably means that there is no justifiable use-case for it.
In Java that is, which has very weak generic programming. Generalizing that to D would be at best speculative. Andrei
Aug 30 2011