Open stewSquared opened 8 years ago
Since this has brought up again via #134, I should share what I've learned.
I've tried removing Util from various objects. This worked fine for tags and attrs, but gets really messy for styles. See my WIP here: https://github.com/stewSquared/scalatags/tree/implicits-import
A better option might be to dig into what's causing the implicits to fail in the first place. I would expect implicit shadowing to solve the problem, since everything that extends Cap/Util, should have implicits of the same name and type. But implicit shadowing seems to be failing. I suspect has something to do with the roundabout inheritance/mixing happening here. The implicits no longer have the same type because Frag
, Modifier
, etc., all have different types in these objects, causing shadowing to fail.
Maybe someone can come up with a minimal example?
I've just bumped into this again; it seems that even small things like import scalatags.JsDom.svgAttrs._
also pulls in implicits, which can conflict. I think we should get rid of most of the implicits except for those in .all
and .implicits
, to avoid conflict
This comes up every now and then in the gitter:
Basically,
implicits
doesn't have enough traits to be used independently likeall
orshort
.Instead of just extending
Aggregate
, it should also extendDataConverters
andUtil
. That last one is tricky, though, because you can only import._
from a single object that extendsUtil
(orCap
) or lose implicits to ambiguity. The fact that each oftags
,tags2
,attrs
,styles
,styles2
,svgTags
,svgAttrs
extendsCap
is then extremely limiting. Sensible sounding imports like the following break:I suggest refactoring these packages so that only
all
,short
, andimplicits
extendUtil
.I have a proof of concept diff for just the refactor of
tags
andimplicits
. The basic idea is to have most packages import from a member of type Util rather than extending it. If that looks like the right direction, I can apply that to the rest and turn it into a PR.