trait
SpireProperties extends AnyRef
Abstract Value Members
-
abstract
def
bases: Seq[(String, SpireProperties)]
-
abstract
def
name: String
-
-
abstract
def
props: Seq[(String, Prop)]
Concrete Value Members
-
final
def
!=(arg0: AnyRef): Boolean
-
final
def
!=(arg0: Any): Boolean
-
final
def
##(): Int
-
final
def
==(arg0: AnyRef): Boolean
-
final
def
==(arg0: Any): Boolean
-
final
def
all: Properties
-
final
def
asInstanceOf[T0]: T0
-
def
clone(): AnyRef
-
final
def
eq(arg0: AnyRef): Boolean
-
def
equals(arg0: Any): Boolean
-
def
finalize(): Unit
-
final
def
getClass(): Class[_]
-
def
hashCode(): Int
-
final
def
isInstanceOf[T0]: Boolean
-
final
def
ne(arg0: AnyRef): Boolean
-
final
def
notify(): Unit
-
final
def
notifyAll(): Unit
-
final
def
synchronized[T0](arg0: ⇒ T0): T0
-
def
toString(): String
-
final
def
wait(): Unit
-
final
def
wait(arg0: Long, arg1: Int): Unit
-
final
def
wait(arg0: Long): Unit
Inherited from AnyRef
Inherited from Any
This trait abstracts over the various ways how the laws of a type class can depend on the laws of other type classes. An instance of this trait is called a property set.
For that matter, we divide type classes into kinds, where the classes of one kind share the number of operations and meaning. For example,
Semigroup,MonoidandGroupall belong to the same kind. On the other hand, their additive variants also belong to a common kind, but to a different one.Users of this trait should extend the outer trait Laws and create specialized subtypes for each kind of type class. (See DefaultProperties for an example.)
Consider this example hierarchy:
Semigroup | \ Monoid AdditiveSemigroup | \ | Group AdditiveMonoid \ | AdditiveGroupThey all define their own laws, as well as a couple of parent classes. If we want to check the laws ofAdditiveGroup, we want to avoid checking properties twice, i.e. do not want to checkMonoidlaws viaGroupand also viaAdditiveMonoid.To address this problem, we define the parent in the same kind as parent, and other parents as bases. In this example, the parent of
AdditiveGroupisGroup, and its only basis isGroup. On the other hand, the parent ofGroupisMonoid, and it does not have any bases.The set of all properties of a certain class is now defined as union of these sets:
Looking at our example, that means that
AdditiveGroupincludes theMonoidlaw only once, because it is the parent of its basis. The same laws are ignored by its parentAdditiveMonoid, hence no redundant checks occur.Of course, classes can have multiple parents and multiple (named) bases. The only requirement here is that inside one kind, the identifier of a property is unique, since duplicates are eliminated. To avoid name clashes between different kinds, the names of properties pulled in via a basis are prefixed with the name of the basis.
For better type-safety, parents are only allowed to come from the same outer instance of Laws, whereas bases are allowed to come from anywhere.