https://pantsbuild.org/ logo
#development
Title
# development
a

average-vr-56795

12/11/2018, 7:39 PM
@aloof-angle-91616 Any thoughts on how we could ergonomically typecheck datatype tuple contents?
a

aloof-angle-91616

12/11/2018, 7:40 PM
are you thinking about reaching into datatypes and pulling out the constituent elements? or do you mean typechecking them after construction?
a

average-vr-56795

12/11/2018, 7:42 PM
At construction
a

aloof-angle-91616

12/11/2018, 7:43 PM
not trying to play dumb -- separately from the current typechecking?
a

average-vr-56795

12/11/2018, 7:44 PM
Right now we can check that a field is a tuple, but that's less useful documentation than
tuple<HydratedTarget>
a

aloof-angle-91616

12/11/2018, 7:44 PM
!!!!!!!!!!!
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