You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ModularSchemeLattice uses a sealed inner trait Value (and inner case classes that extend this trait) to efficiently represent a product lattice of several sublattices. A side-effect of doing so is that all values represented in the analysis are composed of inner case classes that belong to a particular (outer) ModularSchemeLattice instance. This makes it impossible to directly compare values between different analyses if they represent values using different ModularSchemeLattice instances (even if they have the exact same configuration and/or would be considered equal). As a less-than-ideal workaround, maf.modular.scheme.SchemeDomain currently pre-instantiates a few ModularSchemeLattice instances for common configurations, and ensures these are shared between different analyses that use the same configuration. Using inner classes to represent values also poses challenges to proper serialisation/deserialisation (e.g., deserialise(serialise(v)) != v), which is necessary to persist analysis state (cf. #13).
Factoring the trait Value out of ModularSchemeLattice should resolve these issues.
However, doing so naively might introduce difficulties in dealing with all types (and typeclasses) used by the sublattices.
Alternatively, one might want to wait for the arrival of Scala 3's union types, which be might able to replace the inner Value trait inside ModularSchemeLattice easily without the downsides that come from using inner case classes.
The text was updated successfully, but these errors were encountered:
noahvanes
changed the title
Factor our the inner Value trait in ModularSchemeLattice
Factor our the inner Value trait in ModularSchemeLattice
Jan 19, 2021
ModularSchemeLattice
uses a sealed inner traitValue
(and inner case classes that extend this trait) to efficiently represent a product lattice of several sublattices. A side-effect of doing so is that all values represented in the analysis are composed of inner case classes that belong to a particular (outer)ModularSchemeLattice
instance. This makes it impossible to directly compare values between different analyses if they represent values using differentModularSchemeLattice
instances (even if they have the exact same configuration and/or would be considered equal). As a less-than-ideal workaround,maf.modular.scheme.SchemeDomain
currently pre-instantiates a fewModularSchemeLattice
instances for common configurations, and ensures these are shared between different analyses that use the same configuration. Using inner classes to represent values also poses challenges to proper serialisation/deserialisation (e.g.,deserialise(serialise(v)) != v
), which is necessary to persist analysis state (cf. #13).Factoring the trait
Value
out ofModularSchemeLattice
should resolve these issues.However, doing so naively might introduce difficulties in dealing with all types (and typeclasses) used by the sublattices.
Alternatively, one might want to wait for the arrival of Scala 3's union types, which be might able to replace the inner
Value
trait insideModularSchemeLattice
easily without the downsides that come from using inner case classes.The text was updated successfully, but these errors were encountered: