closes #2019: Use parentheses for arity-0 methods which are not refer…
I can agree on having side-effecting methods have parens.
I sort of let the previous PullReq slide since impact was low and it's not our own method (currenttimeMillis),
but you'll have to sell me the idea that we should treat referential opaqueness as side-effecting.
I don't care about whether being not referentially transparent should be called side-effecting or not. What bothers me is the fact that a def without parentheses looks like a val. This is misleading. Didn't you already see issues with passing the sender (should be sender()) along to some computation that might happen in the future and/or in another thread?
To speak with Daniel S. (who shares my point here): In my opinion not using parentheses is just wrong.
By the way: If you look at the Akka code, you will see that some occurrences of the methods I fixed already used parentheses. You should at least be consistent.
You'll be able to use it without parenthesis no matter if it is declared with or without parenthesis.
Sure, this is a little annoying. Hence it is even more important to be consistent on the definition side!
What's the best documentation? Code! While the majority of the Akka code shows excellent style, it offers poor documentation in this regard.
Also look at autocompletion in IDEs: If you use the parentheses they will show up in the autocomplete preview, at least in the latest Scala IDE for Eclipse.
The problem is that it will offer no help whatsoever, since you do not immediately understand when you're closing over "this" or not. IMHO the problem of capturing "this" needs to be solved by some other means than sprinkling parens and hoping people understand the consequences.
I do, however, agree that we should strive for uniformity no matter which side of the fence we are on.
Yes, we need better protection, if possible. But using the parens is not useless. It is a convention, like so many others. It will make at least some users (like me) aware of the issue.
I prefer having parens for a slightly different reason: it reduces breakage if you replace the def with a val returning a Function0. Ideally there shouldn't be a difference between a method and a function in Scala, and so I try to make my code reflect that (although I do break this rule often, it isn't on purpose).
Another disadvantage of not having parentheses at definition side: Some users (like me) would like to use parentheses on call site. This is not possible with the current no-parens style.
That, on the other hand, is a very valid argument.
All right, if this is a valid argument, then let's merge this one ...
Didn't Josh say that the semantics of () had changed?
He is wrong, nothing changed. You can try yourself:
Welcome to Scala version 2.10.0-20120420-191528-3c9c18ddcc (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_31).
Type in expressions to have them evaluated.
Type :help for more information.
scala> def foo() = ()
scala> def bar = ()
<console>:9: error: Unit does not take parameters