Proposed Changes and Restrictions For Implicit Conversions

One place this runs into trouble is Scalatags, which is ~identical to Laminar, except it uses a type alias for Modifier in a generic Bundle trait. This is because it provides multiple implementations - a Text-based implementation, a DOM implementation, and a virtual-DOM implementation - all of which have different concrete types for Modifier. This is all in line with the “objects as modules” thing that Scala expouses; what used to be a JVM package is now an object, allowing inheritance and abstraction and all that.

Apart from letting the library share code internally, this also allows code sharing of user code between different implementations by programming against the abstract Bundle type (ScalaTags). In this case the concrete implementations are not known statically, but we still need implicit conversions to the abstract Modifier type to work.

It’s possible that the library can be refactored to avoid an implicit conversion to an abstract type, but it might be a pretty invasive refactoring to make that happen.

2 Likes