Too terse and too alien?

[Mikael Grev]

>>> 
>> 
>> Should we optimize for the 1 .% that will have this as an issue, or for the other 999 that have to write the dot all the time?
>> IDEs will warn you, and color code it for you to make the distinction. If your IDE can't do that, change. The problem of them not supporting is will pass. The extra dot will never go away.
> 
> It's not a matter of IDE support; that will come whatever syntax is
> chosen - well, if it's reasonably parseable ;)
> It's really a matter of language design: do you want closures to be
> indistinguishable from methods (and if so, how do you want to handle
> the name clashes?), or do you want to make a difference - at the
> language level! - between invocation of a closure and invocation of a
> method? Note that the dot is merely *one* way of achieving the latter,
> you could well have .invoke or .call or whatever can distinguish a
> call on a variable/field from a call to a method. I'm not advocating
> the dot in particular :)
> Another analogy - properties in C#. They have chosen to make them work
> with = so it's indistinguishable if you're assigning to a field or to
> a property (not 100% true, there are different naming conventions, but
> let's ignore that). They could have chosen instead to make them
> accessible via fake set()/get() methods. Which is better? As you can
> see, it's not a matter of IDE support at all.
> 
> It may be true that only 1% will stumble into a name clash, but if you
> design a language you have to specify corner cases as well. I'm
> personally more confident with writing foo.invoke(...) and being sure
> that foo is a closure than with writing foo(...) and having to
> remember complicated precedence rules that might be triggered if
> someone else later adds a method called foo, maybe even in a
> superclass I don't control at all. It's a personal opinion of course,
> I'm just saying that the decision to follow a path or another does
> change how the language "feels", and not just the parser.

If it will/must be the case that one can add a method in a super class and it will change the binding of the closure in a subclass I agree wholeheartedly.

I would expect same name would not be allowed for a closure field and a method when recompiling.

Cheers,
Mikael