It's actually worse than that because one method application that takes an argument can return either an object that can have a method called on it, or a function which can be immediately applied, or some object that doesn't have the appropriate method but can be implicitly converted to one that does - so without knowing the implementation, there is no unique translation of that string into method calls and objects. Your IDE will probably italicise random words in your DSL code for no obvious reason.
A separate issue is that without knowing the implementation you can write code and not know when or how many times it will be evaluated, because if you pass it into an argument that argument may be call by name.
What it all adds up to is that you can look at a piece of code and have very little clue about what it is actually doing underneath. And what is much much worse - it's usually a leaky abstraction so you actually need to know what it's doing underneath and this happens all the time in common libraries in the name of providing a nice DSL.
The ONLY time it makes sense for me to drop . is for some DSL stuff and some math operator stuff...
But really - this is why you have a style guide. Make your style guide say "Always use . unless a math operator". Then the guy that does
foo map x + y filter < 2 foreach println
gets bonked in the head and told to rewrite it.
You would do the same in Java to the guy who wrote a 600 line method, right? Should the JVM enforce the no 600 line method rule, or can we deal with it in style guides? Because the 1 time I need to write a 900 line method, I am sure glad the JVM doesn't limit me.
In my IDE I'd have no trouble - they show up in different colours.
I kind of agree with you, but I think the flexibility over delimiters actually makes it easier to keep code like this clear - you can write something like
opt.foo{ bar.baz(buz bif baf) }
And it's very obvious which brackets go together and what's at which level of nesting.
It won't be able to figure out the non-delimited version in the parents example. That's the point. By allowing that you've made it harder to read unless the reader has exactly the capabilities of a heavy weight IDE. This may or not be an ok trade-off, but you have to accept that there are cases where people may be reading your code without that benefit.
> It won't be able to figure out the non-delimited version in the parents example. That's the point. By allowing that you've made it harder to read unless the reader has exactly the capabilities of a heavy weight IDE.
Yes it will. This is not Haskell where different functions have arbitrary precedence; Scala functions are evaluated left to right (except a very short list of mathematical operators) unless they end in ':'. The only possible meaning of "a b c d e f g" is the one where b, d and f are methods and c, e and g are arguments. You don't need a heavyweight IDE to work that one out.
2) You've moved the goalposts. The original parent said that he found the call syntax confusing, you responded by saying your heavyweight IDE prevents that confusion from happening, and I pointed out the tradeoff required for that. Now you've gone back and just said it isn't confusing and that it is something you have "to work out".
The fact is, some Scala developers find the call syntax confusing and some Scala developers read Scala code in editors that do not have the power to help them suss that out. That is a cost to the flexibility in call syntax. Is that cost worth it? For some people yes, for some no, but don't deny the cost.
1) Fair enough; I'm very surprised, and will take a look at fixing that. 2) I didn't mean for the user to work it out, I meant that a simplistic highlighting script should be capable of it.
In my view dropping the . should only be done for non-alphanumeric operators, e.g. foo |+| bar |> baz.