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

"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?

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

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

"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.

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

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

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

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

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