Collection type highlighting (poll) Follow
Though I like the concept of collection mutability differentiation per se, the current implementation has several flaws:
- There's too much of unnecessary noise for immutable code.
Highlighting is expected to point possible problems, but not to underline all places that are OK.
All such “OK” underlinings form a mix-up with true errors and warnings and require a lot of additional attention.
The SNR is very low:
- The differentiation is limited to the IDEA editor – the structure of code itself is still ambiguous.
The initial problem is not inherent in Scala language itself, but arises from the collection library design (name clashes).
We can solve the problem using the language (but not IDE) means.
The proposal is to implement a known Twitter Scala team guideline: an explicit
So, we need to:
- Ensure there’s no explicit or wildcard (
collection.mutable._) mutable type imports
(show warnings, suggest transforming into
import collection.mutable, auto-import properly).
- Ensure all mutable collection types are prefixed with proper qualifier (
val map = mutable.Map(1 -> ‘foo)).
- Let all good code (95%?) be free :)
Please, post your suggestions. Which implementation would you prefer?
Please sign in to leave a comment.
Language way sounds better. To other seems to have too much noise in editor.
my scala color profile is already very colorful, and i don't mind adding even more information. however, i would only highlight mutable collections since they are the dangerous ones. immutable ones don't need additional highlighting.
going a step further: why not provide that highlighting for *all* mutable classes? checking whether or not a class is mutable could be done by check if it contains a mutable class or a var which is written to or by an annotation.
imho, "mutable." is more noise than a subtile unterline.
When I first saw those markers, I thought they were error markers...
"Please go the Twitter Scala team way" (https://twitter.com/#!/przemekpokrywka/status/190083139635388418)
"We use 'mutable.' prefix for mutable collections. Would be happy to have underline marker when prefix not present." https://twitter.com/#!/ijuma/status/191996197483978752
Mutable and Immutable Collections - Scala 2.8 Collections API:
A useful convention if you want to use both mutable and immutable versions of collections is to import just the package collection.mutable.
Then a word like Set without a prefix still refers to an an immutable collection, whereas mutable.Set refers to the mutable counterpart.
I like the mutable prefix convention more than the coloring scheme (perhaps because I'm somewhat color blind). It would be nice if IDEA could help us manage the imports such that using this convention was easy. I've gotten so used to IDEA taking care of imports in Java that the import handling in Scala seems quite primitive in comparison. Heaven forbid I have to actually write an import line! ;)
This feature will be implemented today or tomorrow in more general way. You'll be able to define any set of classes, which must be imported with prefix (so usage of them without prefix will be highlighted with warning). Of course coloring will be disabled by default.
As for imports writing I just added few more import management features (such like name clashes resolving). Please describe all cases when you need to manually fix imports, then I'll try to support them too.
It's been a while since I've done any Scala work so I'll have to try out the new build and see what I can remember.
OK, here's a (possibly) better idea:
Prefix should be added only when imported name clashes with the name that is available by default.
The result of implementing such a rule is basically the same except that there will be no need to explicitly specify include/exclude filters.
For example, currentrly "Buffer" is imported with "mutable" prefix, however there's no "Buffer" classe neither in "scala.immutable" nor in "java.util" packages (besides, buffers are mutable by definition). With the suggested rule "Buffer" will be automatically imported without a prefix.
How is the idea?