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
next sibling 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
next sibling 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
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
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 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
next sibling 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 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
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.



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
Aug 29 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
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
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.



 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
Aug 29 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.



 Yeah. I don't know why it's allowed. I think that C++, Java, and C#




 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




 simply require that either the type name or this be use), but it




 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




 It's not the end of the world if it isn't, but I see no cons to




 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



 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 "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.



 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
Aug 29 2011
prev sibling parent "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=













 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=










 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=










 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=










 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 =










 code to begin with).

 - Jonathan M Davis



 C# doesn't and I'm fairly sure Java doesn't either (though I'm certai=







 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 abo=





 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