We also use implicits only as context definition (as thread variables). Or it is the thing which every one must know by heart as language grammar.
Depends on the library. Some libraries abuse implicits and other language features (hello, Slick). But usually using help from IDE makes things very clear. Take IntelliJ IDEA for example. If you have an implicit conversion and want to see where is the implicit conversion then use Ctrl+Shift+Q. If you have an implicit parameter and want to see where it comes from then use Ctrl+Shift+P. See here for more info: You will be redirected shortly
Sadly, if we are writing new code then IDE often doesnât help much with finding proper implicit parameters and/ or conversions combination. But for already written and working code, IDE support (i.e. Ctrl+Shift+P and Ctrl+Shift+Q in Intellij) often removes all the magic from implicits. Compare that to annotation driven development or aspects in Java and use of ThreadLocals. These things are actually magic. You cannot even see the code that Spring, Hibernate, Guice, Mockito, etc produces, not to mention analyze, change or debug it. ThreadLocals subvert the ability to do asynchronous programming, because offloading work to another thread means losing ThreadLocal data access (unless we pull the data from ThreadLocal storage and pass it around manually, in which case whatâs the point with ThreadLocals?).
Update:
I didnât see @mdedetrich was already talking about implicits, but Iâll leave this post as it presents somewhat different perspective.
By implicit conversion I mean also those kinds of conversions that are used to provide extension methods. Extension methods wonât be removed from future Scala versions, only implemented differently. But currently extension methods are implemented using implicit conversions so proper IDE support for them is very much welcome.
Nevertheless it is more difficult and I agree that in many cases it is too complicated.
We just forbid to create implicits without special approvement
So I do not understand why they recommend to use implicits as builder pattern.
Use implicits to make structure is obvious bad style for me.
And it seems that I am not the only one who think the same.
So I am sure that
Is a bad vision.
I have tried to summarize discussion for our company(we use kotlin,java,scala):
And our checklist is
- when you need jvm and statically typed language
- use java
- when you write low level decision (application server)
- use kotlin
- when you need high level decision(web app)
- when there are enough standard arithmetic with java types(int,Bigdecimal,String, etc)
- use scala
- when you need high level decision
- when you really need custom arithmetic
- use java
There are options of course, it is just simple start point.
We specialize on data processing.
So if scala had successful whitebox macros or just external preprocessors I would have arguments against the second option.
It would be also usfull:
- xml literals is deprecated
It is useful sometimes - delayedinit is deprecated
It is just argument for kotlin - symbol literals is depricated
We need good dynamic mutable\immutable pojo - etc
1 Like
implicit keyword is used for many different purposes. Implicit conversions, extension methods and implicit parameters (inlucing context bounds). What is considered bad practice are implicit conversions per se. Implicit functions are functions with implicit parameter, so that doesnât make them bad practice.
No, it does not.
I do not know universal rule which do not lead to holywar.
We use principle:
If someone read code in text editor and do not understand what it is going on because of implicits it is a bad practice.
So, we use implicits
- instead of thread variables(it is evil in any case)
there are 2 such implicits in our framework - to make constants, for exampl 2.nn is equavalent to NNumber(2)
Everybody know it by heart. - context bounds
def f[A : B]
implicit should be in object A
So there are no need for
IMHO If you need IDE help it is a bad practice 
Thereâs no point in making everyone happy. You canât satisfy everyone at the same time.
Some Java programmers were scared by var keyword. They say they do not understand code with vars if they are reading it in text editor, so they prefer explicit types.
1 Like
I have said very different thing. All implicits( except context bound) must be known by heart by everyone
it is not like library extension it is more like language extension.
It is very expensive
Either that, or it has to be something that if you need to examine, you use an IDE, and you can understand the code at least superficially, without an IDE.
An example of that is Ordering. You can read xs.sortBy(f) without having to know about implicits, unless you need to examine it more closely. So if you can assume that anyone that needs to examine it more closely has the requisite tooling (such as the latest IntelliJ Scala plugin), then you donât have to assume memorization.
The other side of that coin is that when designing a library and deciding how implicit-heavy it will be, you are deciding what level of understanding it is possible to get without implicit-examining tools. For example, from just reading code that uses Slick, you donât know much about the machinery thatâs deciding how to work with your types. That machinery plays a pretty significant role in the behavior of the code. At the same time, Iâd kind of rather not have that part written out. If it was explicit, it would be much harder to see the more important part of the code, such as the columns or queries Iâm defining. (But no question, now that IntelliJ can show the implicit parts as if they were written out, I would sometimes turn that on.)
1 Like
May be it is most undeniable implicit feature.
There is other very important thing, it is the amount of brain to understand it 
There are two important moment in that joke:
- The less brain is needed by you to read and write, the more brain you can spend on solving business task
- I think there are mostly very smart people in this forum. But there are many usual people which can not be so smart for scala, but they can be usually much better for business task.
It is very hard to prove, but take into account some practice, for example:
Or let us just look on kotlin
We are not lazy to think, we just want to think more about business tasks and about people.
I think it is really killer feature.
You just do not need to learn by heart where you need to write import someUnknownWord._
see also:
1 Like
Show me code with lots of receiver functions. Will it be only about mutable DSLs?
I have discussed a lot that question in other topics, so I would prefer not to repeat it here.
I have not thought much about it. We need better
- scope managment
- builder pattern
So no publicly available code to discuss? Then it doesnât seem receiver functions are popular.
There are a lot of examples in other topics.
It seems so for scala users 
But kotlink users sometimes troll me :))
1 Like
All I see is mutable HTML DSLs harassed over and over. HTML is easy. Show me how do you deal with CSS with receiver functions 
Immutable type-safe HTML DSLs should be doable using type unions (available in Dotty), e.g.:
object HtmlDsl {
type HtmlChild = ElemHead | ElemBody
type HeadChild = ElemMeta | ElemTitle
type BodyChild = ElemTable | ElemP
def html(items: HtmlChild*): ElemHtml = ???
def head(items: HeadChild*): ElemHead = ???
def body(items: BodyChild*): ElemBody = ???
}
IDE should be able to suggest matching methods in auto-complete, i.e. IntelliJ already sorts method in auto-complete putting methods with correct result type first.
Here you have your killer feature In FP form (immutability oriented) instead of typical OOP form (mutability oriented).
I have never said that it is killer feature for FP. I have thought it is obvious.
I have not seen simple scope management here.
Show me an example where it is not sufficient.
Yes you can make it somehow without delayedinit.
Just show me the way you can do it such way which can fit our company standards of simplicityâŚ
Which classes in ScalaFX use DelayedInit?