Looking at transformation methods in typeclasses, I wonder about how to keep binary compatibility in the future.
Suppose that library A depends on non/algebra version 1 to implement a few typeclasses.
In non/algebra version 2, helper methods such as Semilattice.asMeetPartialOrder are added.
Now, suppose that library B depends on non/algebra version 2; on objects originating from library A, the Semilattice.asMeetPartialOrder methods will either not be available, or subtly break down (see scala/scala-dev#35).
My opinion: typeclasses should expose a minimal surface consisting of the operations of the algebraic structure only. Implicit extension methods should then be used to provide asMeetPartialOrder, even taking an implicit parameters to allow specialized transformations.
Another point to settle about binary compatibility: additional typeclasses can be added without breaking binary compatibility, except when they are inserted in the inheritance scheme. As of now, non/algebra is not including semicategories, categories, groupoids, magmas, quasigroups, loops ( according to https://en.wikipedia.org/wiki/Algebraic_structure ). I'm not in favor of including everything and the kitchen sink --- we should decide on what's not included and document it.
(We have to be extra-careful about binary compatibility --- if successful as an unifying project, non/algebra will be depended on by many projects for interoperability).
Looking at transformation methods in typeclasses, I wonder about how to keep binary compatibility in the future.
Suppose that library A depends on non/algebra version 1 to implement a few typeclasses.
In non/algebra version 2, helper methods such as
Semilattice.asMeetPartialOrderare added.Now, suppose that library B depends on non/algebra version 2; on objects originating from library A, the
Semilattice.asMeetPartialOrdermethods will either not be available, or subtly break down (see scala/scala-dev#35).My opinion: typeclasses should expose a minimal surface consisting of the operations of the algebraic structure only. Implicit extension methods should then be used to provide
asMeetPartialOrder, even taking an implicit parameters to allow specialized transformations.Another point to settle about binary compatibility: additional typeclasses can be added without breaking binary compatibility, except when they are inserted in the inheritance scheme. As of now, non/algebra is not including semicategories, categories, groupoids, magmas, quasigroups, loops ( according to https://en.wikipedia.org/wiki/Algebraic_structure ). I'm not in favor of including everything and the kitchen sink --- we should decide on what's not included and document it.
(We have to be extra-careful about binary compatibility --- if successful as an unifying project, non/algebra will be depended on by many projects for interoperability).