there's a comment i left in

Collection.of()

to type-check its contents somehow, let me look at that for a sec

and i forgot only tuples are hashable, which simplifies this a bit

there are two ways i was thinking about this in the default values for datatypes diff

(1) where we check types in ctors, use

satisfied_by

, and allow `TypeConstraint`s to do arbitrary checking things there, with the knowledge that it runs synchronously. i don't think this is a bad idea whatsoever

(2) expand what we allow for

obj_type

in

satisfied_by_type

(for example) to also allow an instance of some other specific class which represents a collection (also not a bad idea, less scary and probably cleaner)

if we do (2), we may want to do what we've done with the datatype

__eq__()

method and have a canary so

satisfied_by()

can't be overridden (which gives us the ability to do (1) later, if we want)

(2) is already coming together in my head

i can provide example code if it's not clear

thinking about the second half of (2) which is probably -- we add a

@classproperty

to datatypes which returns a tuple of types for the datatype fields, or instead of a type, a field may instead be associated with an object that represents a parameterized collection

it wouldn't be hard actually to avoid having each

TypeConstraint

handle collections separately, i think

and i think this would gracefully degrade to the normal typechecking if we try to use `TypeConstraint`s outside of the datatype contedxt

those are some thoughts

and this is easily extensible to sets or other collections, as long as those are hashable (not even necessary, just for datatypes going through the engine we need hashability)

even that could be hacked on