I think the idea of computed fields implemented via methods is better represented via C#-style properties, although I'd prefer to be able to access their methods directly, when suitable.
foo.Sort(x.compare _)
And Scala's getters and setters are essentially equivalent to C#'s properties: class A {
private var _x = 0
def x = _x
def x_=(value: Int) { _x = value }
}
val a = new A
a.x = 5
println(a.x)This is not an improvement, it is an unnecessary complication.
There is a simple, unambiguous rule -- () calls, no-() references. In order to... what? save two keystrokes? -- you have added a strange corner case, and then tacked on a new bit of punctuation for partial application. Though now it seems you're adding the rule that functions without parameters can't be referenced.
This takes a simple yes-or-no rule and adds edge cases for no reason. Two keystrokes on the occasional parameterless function call is not a real savings, and you've just made it harder for someone reading the code to spot all the function calls.
This fundamentally makes no sense. Why would this be a good idea?
I used scala for a while, I admit there's a whole bunch of features that can get you confused. This takes 30s to spot.
To quote Odersky: "This convention supports the uniform access principle which says that client code should not be affected by a decision to implement an attribute as a field or method."
It makes sense if you want to implement something that may be a field but needs to be computed.