3 ms·

One of the worst syntactical aspects of Scala is that you can define methods which cannot be called with invocation parentheses. Why anyone would ever want this

by mlthoughts2018 8y ago

One of the worst syntactical aspects of Scala is that you can define methods which cannot be called with invocation parentheses. Why anyone would ever want this is beyond my understanding.

emodendroket 8y ago
You're supposed to distinguish between functions with side effects and those with none.
- mlthoughts2018 8y ago
  What about methods that have arguments and no side-effects, like a special getter that accesses a value in a Map of Maps? or functions that flush state to I/O while doing other stuff and returning a value? Why only make a special weird distinction for arg-less methods? And why enable different ways of defining the method that can optionally require you to omit parentheses rather than choose to do it only when you choose to write a function that embodies that convention? If you want a way to indicate side effects, make it a part of the type system like in Haskell. Such a silly convention is unhelpful and I think fails even at the intended goal because it confuses people thinking it’s not involving the overhead of a function call.
  - emodendroket 8y ago
    Doesn't seem that different from the C# concept of properties, except with a bit less language support. To me it doesn't seem that worth worrying about the overhead of trivial function calls in the general case.
    - mlthoughts2018 8y ago
      But they often aren’t trivial, e.g. like breeze conversions to Scala data structures that appear like simple attribute accesses and don’t indicate at all that really they are complex function calls with important performance considerations.
noelwelsh 8y ago
This is the "uniform access principle": https://en.wikipedia.org/wiki/Uniform_access_principle https://en.wikipedia.org/wiki/Uniform_access_principle
- mlthoughts2018 8y ago
  I’m well aware. It’s just a bad concept. Knowing that something behaves as a function invocation is extremely important. The idea that this knowledge should not have consequences for the mental model of the caller is a bad idea. Setting up a design that achieves this (where, from the caller’s perspective, attributes vs side-effectful argumentless methods appear the same) results in a bad design. I see this a lot with Named Principles and Design Patterns. They have Capitalized Names and Entries on Wikipedia so people believe they are Pragmatically Successful and Deserve Respect. But they are usually just junk. Things like Liskov, all kinds of nominal design patterns, mischaracterizations of least astonishment, etc. A good heuristic is to ignore all that garbage and just use common sense.

One of the worst syntactical aspects of Scala is that you can define methods which cannot be called with invocation parentheses. Why anyone would ever want this is beyond my understanding.

emodendroket 8y ago

You're supposed to distinguish between functions with side effects and those with none.

mlthoughts2018 8y ago
What about methods that have arguments and no side-effects, like a special getter that accesses a value in a Map of Maps? or functions that flush state to I/O while doing other stuff and returning a value? Why only make a special weird distinction for arg-less methods? And why enable different ways of defining the method that can optionally require you to omit parentheses rather than choose to do it only when you choose to write a function that embodies that convention? If you want a way to indicate side effects, make it a part of the type system like in Haskell. Such a silly convention is unhelpful and I think fails even at the intended goal because it confuses people thinking it’s not involving the overhead of a function call.
- emodendroket 8y ago
  Doesn't seem that different from the C# concept of properties, except with a bit less language support. To me it doesn't seem that worth worrying about the overhead of trivial function calls in the general case.
  - mlthoughts2018 8y ago
    But they often aren’t trivial, e.g. like breeze conversions to Scala data structures that appear like simple attribute accesses and don’t indicate at all that really they are complex function calls with important performance considerations.

noelwelsh 8y ago

This is the "uniform access principle": https://en.wikipedia.org/wiki/Uniform_access_principle https://en.wikipedia.org/wiki/Uniform_access_principle

mlthoughts2018 8y ago
I’m well aware. It’s just a bad concept. Knowing that something behaves as a function invocation is extremely important. The idea that this knowledge should not have consequences for the mental model of the caller is a bad idea. Setting up a design that achieves this (where, from the caller’s perspective, attributes vs side-effectful argumentless methods appear the same) results in a bad design. I see this a lot with Named Principles and Design Patterns. They have Capitalized Names and Entries on Wikipedia so people believe they are Pragmatically Successful and Deserve Respect. But they are usually just junk. Things like Liskov, all kinds of nominal design patterns, mischaracterizations of least astonishment, etc. A good heuristic is to ignore all that garbage and just use common sense.