5 ms·

A fourth is monkey-patching (if you're counting implicit classes, not just implicit arguments to methods).

paulddraper 8y ago
IMO, that falls in DSLs/syntax sugar. But yeah, for most code I'm not a real fan of most "extension methods." Is 5.minutes really superior to minutes(5) or duration(5, minutes)?
- mpartel 8y ago
  In your example, not really, but in general, assuming the implicit is in scope most of the time, `x.method` is much more discoverable through autocomplete than `method(x)`. Incidentally, the fact that Haskell's function calls look like `f x` instead of `x.f` probably makes building a pleasant Haskell IDE quite difficult.
  - pjmlp 8y ago
    Leksah is quite nice.
  - paulddraper 8y ago
    > `x.method` is much more discoverable With an IDE, yes. With a text editor, no. > assuming the implicit is in scope most of the time, And that's really the rub. I write import com.example.MagicThings._ and one of the things imported is an implicit class or method which has the visible on that. The name I see in the code is not even one of the names I am importing, which IMO significantly hurts discoverability.
    - mpartel 8y ago
      Without an IDE, discoverability is not great even in implicitless code. In `x.y.z()`, you don't need to import the type of `y`, much less the method `z`. And an IDE's "go to definition" works fine on extension methods. IMO the greater discoverability problem is knowing and remembering what to import in the first place. Still, even with an IDE, extension methods do add complexity and should only be considered when they'd be called very frequently. In my current (Unity/C#) codebase, the ratio of static helper methods to extension methods is probably around 10:1 or more, and that seems alright. Although it sounds very controversial, it might actually be good if libraries could by default add their implicits to the prelude. SBT (which is horrible in many other ways) lets its plugins do something similar, and that seems to be ok.
- azernik 8y ago
  I feel that it's a bit more than syntax sugar - I'll use this to normalize APIs between different third-party libraries (including the Scala standard library) so that I don't have to remember e.g. whether Slick implemented recover() for DBIOs (hint - it didn't, which breaks the mental abstraction of "this is like a Future, but different") or whether Map()s have a `filterValues()` method to match their `filterKeys()` (again, no).
- seanmcdirmid 8y ago
  If you consider discovery via code completion, then dot notation is better than procedure call notation.

IMO, that falls in DSLs/syntax sugar. But yeah, for most code I'm not a real fan of most "extension methods." Is 5.minutes really superior to minutes(5) or duration(5, minutes)?

mpartel 8y ago
In your example, not really, but in general, assuming the implicit is in scope most of the time, `x.method` is much more discoverable through autocomplete than `method(x)`. Incidentally, the fact that Haskell's function calls look like `f x` instead of `x.f` probably makes building a pleasant Haskell IDE quite difficult.
- pjmlp 8y ago
  Leksah is quite nice.
- paulddraper 8y ago
  > `x.method` is much more discoverable With an IDE, yes. With a text editor, no. > assuming the implicit is in scope most of the time, And that's really the rub. I write import com.example.MagicThings._ and one of the things imported is an implicit class or method which has the visible on that. The name I see in the code is not even one of the names I am importing, which IMO significantly hurts discoverability.
  - mpartel 8y ago
    Without an IDE, discoverability is not great even in implicitless code. In `x.y.z()`, you don't need to import the type of `y`, much less the method `z`. And an IDE's "go to definition" works fine on extension methods. IMO the greater discoverability problem is knowing and remembering what to import in the first place. Still, even with an IDE, extension methods do add complexity and should only be considered when they'd be called very frequently. In my current (Unity/C#) codebase, the ratio of static helper methods to extension methods is probably around 10:1 or more, and that seems alright. Although it sounds very controversial, it might actually be good if libraries could by default add their implicits to the prelude. SBT (which is horrible in many other ways) lets its plugins do something similar, and that seems to be ok.
azernik 8y ago
I feel that it's a bit more than syntax sugar - I'll use this to normalize APIs between different third-party libraries (including the Scala standard library) so that I don't have to remember e.g. whether Slick implemented recover() for DBIOs (hint - it didn't, which breaks the mental abstraction of "this is like a Future, but different") or whether Map()s have a `filterValues()` method to match their `filterKeys()` (again, no).
seanmcdirmid 8y ago
If you consider discovery via code completion, then dot notation is better than procedure call notation.