View mode: basic / threaded / horizontal-split · Log in · Help
August 29, 2011
Overloading static methods
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
August 29, 2011
Re: Overloading static methods
"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?
August 29, 2011
Re: Overloading static methods
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
August 29, 2011
Re: Overloading static methods
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
August 29, 2011
Re: Overloading static methods
"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.
August 29, 2011
Re: Overloading static methods
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
August 29, 2011
Re: Overloading static methods
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.

Yeah. I don't know why it's allowed. I think that C++, Java, and C# 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
August 29, 2011
Re: Overloading static methods
Jonathan M Davis:

> Yeah. I don't know why it's allowed. I think that C++, Java, and C# all allow 
> 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
August 29, 2011
Re: Overloading static methods
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.
>
> Yeah. I don't know why it's allowed. I think that C++, Java, and C# 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

C# doesn't and I'm fairly sure Java doesn't either (though I'm certainly 
no Java expert). Overall, I think this entire "call static method on 
instance" deal comes from C++.

- Alex
August 29, 2011
Re: Overloading static methods
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.
> > 
> > Yeah. I don't know why it's allowed. I think that C++, Java, and C# 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
> 
> C# doesn't and I'm fairly sure Java doesn't either (though I'm certainly
> no Java expert). Overall, I think this entire "call static method on
> instance" deal comes from C++.

I haven't used C# much, so I'm not entirely surprised if I'm wrong about that, 
but I'm 99.99% sure that Java allows it. I definitely remember being irritated 
by it in Java.

- Jonathan M Davis
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home