Re: Issues with the logical consistency of The Third Manifesto

Alfredo wrote:
> What does "the possibility of joining tables and having the proper
> 'class' materialize to handle it" means?

and then Marshall wrote:

> It means that one would like to be able to have a lightweight way
> of having a class (alternatively: a set of methods) associated with
> the rows of a resultset, even if this resultset came from a join, so
> that one could directly go from a query to a set of objects.

This is, in the words of Frank Zappa, the crux of the biscuit. A relation (derived perhaps via one or more JOINs) has a more specific type than relation; for this discussion, let's call the type of one of its tuples the "tuple-type". The tuple-type can be derived from the relational expression. To define an operator over that tuple-type would be to define it in terms of its attributes, right? So what value (other than perhaps namespace) does associating that operation with the tuple-type have?

I think of this as a potential shortcut, but of far less value than the encapsulation that can be used with an OO language to define types. It would be defining an operation "Result foo(Tuppleware)" where Tuppleware is a shortcut for {t1 a2, t2 a2, ...}. In fact, given that most operations would be over just a subset of the attributes (e.g. a tuple with StartingDate and EndingDate both of type Date might have a Duration "method" which subtracts them), of what value is it to declare the operator as having a declared domain which is a superset of the actual domain?
I'm not criticizing, just asking and playing devil's advocate...

• erk