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.
ModularSchemeLatticeuses 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)ModularSchemeLatticeinstance. This makes it impossible to directly compare values between different analyses if they represent values using differentModularSchemeLatticeinstances (even if they have the exact same configuration and/or would be considered equal). As a less-than-ideal workaround,maf.modular.scheme.SchemeDomaincurrently pre-instantiates a fewModularSchemeLatticeinstances 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
Valueout ofModularSchemeLatticeshould 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 innerValuetrait insideModularSchemeLatticeeasily without the downsides that come from using inner case classes.