m.invoke() vs. m() vs. m#()

[Peter Levart]

On Sunday 13 December 2009 12:25:22 Vladimir Kirichenko wrote:
> Why be unambiguous here? For what? Just to have ability to name
> everything with the same name?

Well, just to stay simple in case it happens that someone names different things with the same 
name. We know we can have a class, a method and a variable in context using same names, but 
there's no ambiguity in their usage since it is expressed using different parts of Java syntax.

> 
> Why don't we have special syntax for making unambiguous:
> * interfaces: class X interface %X
> * enums: class X{} enum $X{};
> * constructors (why not?): class X { ~X(){} }
> * final fields/variables: public static final String &CONST;
> * static methods:  C.*m*();
> * !this()
> * ^super()
> 
> Every of above examples could be supported with every argument against
> ambiguity shown here. Why don't we have it?  And having this things
> ambiguous we seem not have any problems with "ambiguity".

Your examples are not parallels to mine. You suggest having special syntax "additions" for 
specifying symbol names of "different" things. There's no ambiguity in current Java syntax for 
specifying symbol names of different things:

class X ...

vs.

interface X ...

The first example unambiguously declares a class and the second an interface.

> 
> Closure is a function. It's a natural to call function, any
> function(constructor, static method, this(), super()) without pointing
> out with verb "call it" or hieroglyph defining the same.
> 

Well, you're right this time. We're at least trying to make it seem like it is.

It was just a thought.

Peter