closes #2019: Use parentheses for arity-0 methods which are not referent... #417

Merged
merged 1 commit into from Apr 27, 2012

Projects

None yet

3 participants

@hseeberger
Contributor

...ially transparent

@viktorklang
Member

Sorry man,
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.

@hseeberger
Contributor

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.

@viktorklang
Member

You'll be able to use it without parenthesis no matter if it is declared with or without parenthesis.

@hseeberger
Contributor

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.

@viktorklang
Member

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.

@hseeberger
Contributor

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.

@derekjw
Contributor
derekjw commented Apr 24, 2012

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).

@hseeberger
Contributor

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.

@viktorklang
Member

That, on the other hand, is a very valid argument.

@hseeberger
Contributor

All right, if this is a valid argument, then let's merge this one ...

@viktorklang
Member

Didn't Josh say that the semantics of () had changed?

@hseeberger
Contributor

He is wrong, nothing changed. You can try yourself:


tmp$ scala-2.10
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() = ()
foo: ()Unit

scala> foo()

scala> foo

scala> def bar = ()
bar: Unit

scala> bar

scala> bar()
<console>:9: error: Unit does not take parameters
              bar()
@viktorklang viktorklang merged commit 55dc510 into master Apr 27, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment