Re: Digest for firstname.lastname@example.org - 4 updates in 1 topic
+1 I think the solution to the problem is not so much the implicit themselves but the tooling.
For myself, just being able to spot "magic" code is enough. Once I realize something strange is going on, debugging it is pretty quick. Agree that lightly under-lining implicit conversions is not obvious enough, and IntelliJ does not highlight functions with implicit invisible args at all.
I don't think that it should be any argument to the fact that implicits are
a major hindrance to language adoption as I have previously laid it out in
a pretty long epic thread
<https://groups.google.com/forum/#!topic/scala-user/iI4u3Xqs5K0>. Nor do I
think many would disagree that they can cause major headaches such as spending
7 hours looking for an implicit
as I have previously said I am actually a fan of the Scala language so I
have been thinking about a productive and forward thinking solution to the
problem without compromising all of the features that
implicits legitimately provide. I think the solution to the problem is not
so much the implicit themselves but the tooling.
Consider a java program for example that referenced a function not declared
in the source, it would be simple to cmd-click (or ctrl-click) to navigate
to that declaration and see where it is declared. Of course when you
importa java class, you don't automatically import the imports that the
java class makes. This isn't the case with implicits. So finding them is
opaque, knowing where they come from is opaque and thus the nightmare.
However, if you are using java and editing with vim the nightmare may be
slightly less but still is impressive.
To solve this I think Lightbend (which is a major proponent and advocate of
Scala) and ScalaLang.org need to start working together heavily with IDE
makers such as IntelliJ on the tooling in an extremely cooperative manner.
The current Scala tooling is more of a java tooling with some things bolted
on. There is scant attention paid to making things that are tough in Scala
and have no analog in java. An implicit conversion, for example, is lightly
underlined in IntelliJ but you cant find what it was converted to or what
the import was. If you use a macro (which I wouldn't suggest by the way)
then there is no tooling to let you know what the expansion of that macro
will be. Furthermore almost every developer has been hit by obscure
warnings that are less than helpful. Note that I don't have anything
against eclipse but I don't prefer it as an IDE for many reasons. Instead
of this tooling being something done by third parties or the vendors
themselves, the two powerhouse organizations i recommended could work
closely and provide tooling that makes the experience easy. Among
recommendations I would propose the following:
- Objects that are implicitly converted should show up in a different color
or have some obvious means of showing that the implicit conversion
occurred, not a subtle light underline.
- There should be a command that you can execute in the key map that will
take you to the declaration of the implicit conversion.
- When copying code from one file to another that utilizes an implicit
conversion, the implicit should be imported for you.
- On the subject of imports, if implicits are imported as a result of an
import that imports other things, the chain should be revealed in some kind
- If there are conflicting implicit conversions that render the resolution
ambiguous it should be easy to navigate to where they are declared.
- The tooling should include a popup when you type the dot and do a
ctrl-space expansion with a list of methods including the implicits
available in another color or font weight or some other means to indicate
it requires an implicit conversion to another type. For example if doIt()
can be called from an implicit conversion of a string the popup could show "
MyImplicits.doIt()" in orange indicating it comes from an implicit
- If you type code that results in a macro expansion there should be a key
to popup a window that shows what the expanded form will be.
- Language syntax that is obscure from the point of view of Java developers
should be able to invoke a popup to explain that syntax. Since java devs
are the most common converts to Scala this would aid adoption.
If the community really makes a concerted effort towards tooling I think
adoption of the language will be even faster and these issues will not
drive people out of an otherwise excellent language.
> To solve this I think Lightbend (which is a major proponent and advocate
> of Scala) and ScalaLang.org
do you mean the Scala Center?
> need to start working together heavily with IDE makers such as IntelliJ on
> the tooling in an extremely cooperative manner. There is scant attention
> paid to making things that are tough in Scala and have no analog in java.
I think that's an unfair characterization.
> you cant find what it was converted to or what the import was. If you use a
> macro (which I wouldn't suggest by the way) then there is no tooling to let
> you know what the expansion of that macro will be.
Macros are a much harder problem for tooling than implicits, so this is
somewhat of a strawman. However, the current macros are being replaced by
the inline+meta type, which will be much more toolable, and the scala.meta
project is seeing to this.
> - Objects that are implicitly converted should show up in a different
> color or have some obvious means of showing that the implicit conversion
> occurred, not a subtle light underline.
> - Language syntax that is obscure from the point of view of Java
> developers should be able to invoke a popup to explain that syntax. Since
> java devs are the most common converts to Scala this would aid adoption.
This already exists.
1. Alt-enter on for comprehension (on the `for` keyword) has a command to
desugar the for comprehension (convert it to the equivalent foreach or
2. Select code and right-click, in the context menu there's "Explain scala
code (ctrl-alt-e)" or "Desugar scala code (ctrl-alt-d)" (it was renamed
recently). You get a whole bunch of choices:
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to [hidden email].
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.