[snip entire conversation so far]
(Please bear with me - I'm going to go in random directions.)
Someone please correct me if I'm wrong, but it seems that there's only
a few things missing in P6:
1) An elegant way of creating a tuple-type (the "table", so to speak)
2) A way of providing constraints across the actual tuples of a
given tuple-type
3) Syntactic sugar for performing the relational calculus
To me, a tuple-type is more than a class in the standard OO. It has to
be able to apply any constraints that might be upon the tuple-type,
such as uniqueness of a given element across all tuples or foreign-key
constraints. While this is certainly possible using the P6 OO
constructs, it would make sense for a baseclass to provide this
functionality.
Actually, this is a really great place for metaclasses to shine. The
actual tuple-type needs to be constructed from some class-constructor
(which would be, in the metamodel, itself a class). This is so that it
has the appropriate types for the elements of the tuple along with any
necessary constraints upon the tuples / elements of the tuples.
In addition, you're going to want to take actions not just on the
tuple, but on the entire tuple-type. That screams class-level methods
that operate across all instances of the class. Maybe, a set of roles
would be good for organizing this kind of across-all-instances
behavior that the tuple-type can take advantage of. I'm sure that this
wouldn't be limited to just the relational calculus.
As for the syntactic sugar, I'm not quite sure what should be done
here. And, with macros, it's not clear that there needs to be an
authoritative answer. Personally, I'd simply overload + for union, -
for difference, * for cross-product, / for divide, and so forth.
There's been some discussion with sets as to creating new operators
using the set-operators that come in Unicode. As tuples and relations
among tuples aren't necessarily sets, those might not be appropriate.
It also seems clear that junctionish iterators may be of use here. For
example, "Give me all the tuples that match this criteria" might
return an iterator that also acts as an any-junction.
It could also return a class object that has a different set of
instances marked as created from it. Though, I'm not too sure how that
would work when asking a given instance "who is the class object that
created you?" ... maybe it returns the initial one or maybe it returns
them all? I think the initial one is more correct, as the others are
just subsets. When dealing with SQL, I don't care about the subsets
that a given row belongs to - I only care about the table. So, maybe
the subset class objects delegate all methods to the original class
object except for those that deal with "Who do you have?" and "Give me
a subset where ..."
Also, joins between tuple-types would have to create a new tuple-type,
with the tuples within being delegators to the underlying tuples? I'm
not sure that this (or any other) derived tuple-type class object
should be allowed to create new tuples (though I'm sure someone can
think of a good reason why I'm wrong).
Again, just a bunch of meandering thoughts. Bonus points to whomever
can help me bridge the gap between what I just blathered and an
elegant solution to Sudoku.
Rob
