2 ms·
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
by 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 agoLeksah 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 agoWithout 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.