5 ms·
Implicit conversions are now considered an anti-pattern and not recommended.
by dudul 11y ago
Implicit conversions are now considered an anti-pattern and not recommended.
- k__ 11y agoReally? Nice to know. I had the feeling that "Programming in Scala" prized them as the killer feature, back in 2009 :)
- sesm 11y agoHowever, they are heavily used in standard library, e.g. the dreadful CanBuildFrom
- lmm 11y agoThat's an implicit parameter, something entirely different. It is unfortunate that so many critics conflate the two.
- dudul 11y agoImplicit parameters are not the same as implicit conversions.
- eropple 11y agoImplicit parameters are no prize either, though. They seem to lead to massive, massive snarls in the codebases I end up exposed to regularly.
- the_af 11y agoIs "Pimp my Library", as used to be recommended by Odersky, also an anti-pattern now? It uses implicit conversions, if I'm not mistaken.
- dudul 11y agoIt does, and yes I think it is now considered an anti-pattern. The proper way (IMO) to extend libraries is to use type-classes.
- sjrd 11y agoNo, Pimp my Library is not an anti-pattern. It even received dedicated syntax with `implicit class`es. Contrary to general implicit conversions, implicit classes are not dangerous because things are not actually converted as far as the developer can see (yes, under the hood, it's an implicit conversion, but it doesn't bite you). You're simply adding methods on existing classes, which is similar to extension methods in several other languages.
- wtetzner 11y agoAnd in fact, if you combine implicit classes with values classes (e.g. implicit class RichFoo(val value: Foo) extends AnyVal { ... }) then you're effectively just adding extension methods, and there's not even an allocation involved.
- the_af 11y agoI didn't even know implicit classes existed. Thanks!
- jinst8gmi 11y agoIt would be more accurate to say that abuse of implicit conversions are now considered an anti-pattern. They are a core part of the language e.g. many of the extra functions Scala adds to java's String class.
- vkjv 11y ago> implicit def intToFloat(x: Int) = x.toFloat I've seen code like this pop up way more than I'm comfortable admitting.
- brianwawok 11y agoYou can write bad code in any language.
- wtetzner 11y agoThis is true, and in some ways I get annoyed by this saying, because it doesn't add much value. I think there are two better ways of evaluating a language in terms of good code/bad code: 1. Does the language (and its idioms) encourage good or bad code? 2. Does the language support strong enough abstraction facilities to allow good code to be written? Now, of course, the problem is that people will disagree about what counts as good code, but these at least make you think about what's important in a language. Edit: Formatting
- kodablah 11y agoThis is an anti-pattern IMO and requires an import to opt-in (by the author, not the caller IIRC). Instead you'd use an implicit value class which should be zero overhead. But that's just about the definition, not what it's doing which is no good. Anyone can abuse a lot of these features, which depending upon who you'd ask, is better flexibility than not having them at all.
- extempore 11y agoThis is such an interesting choice of example because this particular implicit is baked into the language, and the discomfort you feel is a fine measure of how good an idea this is. Last I checked there was no way to turn it off. scala> def f(x: Float) = x.round f: (x: Float)Int scala> f(123456789) res0: Int = 123456792 But of course it doesn't stop at converting Ints into Floats. scala> f(Long.MaxValue) res1: Int = 2147483647 So it seems 9223372036854775807 rounds to 2147483647. This can be a real simplifier if your "big data" is getting too big.