Re: Storing data and code in a Db with LISP-like interface

Dmitry A. Kazakov wrote:
> On Mon, 01 May 2006 21:36:58 GMT, Bob Badour wrote:
> >
> > That's interesting. What OO language supports basic set operations on
> > object, classes or whatever? Where is the OO union? Intersect? Join?
> > Cartesian product? What is the OO equivalent to project?
>
> 1. Objects
>
> There is no set operations on objects if they are not sets (=do not expose
> public set interface) but it is easy to have such. A "Set" ADT is trivial
> to design. Surely you wouldn't claim that numbers are not based on the set
> theory, just because they don't have operation "intersect." Intersection of
> two numbers is not a number. Same is true for most of types of objects.
>
> To be based on X /= implements X
>
> 2. Sets of objects
>
> Take any container library. They customary have sets, maps, bags of
> objects. Note that sets of objects of different types is also possible.
> These are class-wide containers (ones of polymorphic objects.)
>
> 3. Types
>
> This is more challenging and here set theoretical operations are supported
> at full. To produce new types:
>
> 3.a. Union -> Multiple inheritance in virtual bases
>
> 3.b. Intersection -> Constrained subtypes, disallowing methods (the most
> widely used case is T -> const T)
>
> 3.c. Join -> Inheritance with adding new methods. (Also much desired, but
> rarely supported generalization by adding new values.) Lacks of types
> system in this respect is often circumvented by adding abstract common
> ancestors.
>
> 3.d. Cartesian product: Inheritance with extension (adding new members),
> record types, multiple inheritance in methods.
>
> I am not sure what you meant under "project."
>
> 4. Classes
>
> A class is a closure of a set of types. Isn't it about sets?
>
> 5. Sets of types
>
> The generic programming is all about. Examples are templates and classes.
>
> -----------------
> P.S. Carefully observe 3-5. This is what RM implementations usually lack
> and why OO became more popular. Think about tables of tables and operations
> defined on them. That would be an RM equivalent of generic programming.

This response, while carefully considered, is not compelling. It is almost
entirely about the meta-level, not the data level. While points 1-2 are about
the data level, it nonetheless shows that OOPLs *don't* support the relational algebra. The fact that you could code some up doesn't change that--that's a given. You can code anything up; that doesn't mean the language supports it. I want RA operators as primitives.

Point 3 is telling. It shows how a number of meta-operations in OOPLs are ad hoc restricted forms of relational operations. It was this realization,
some years ago, that led me down the path of studying relational languages as a replacement for OOPLs. I would vastly prefer the clean and straightforwardness of the relational algebra (at the meta level) than the wonky inheritance rules of any OOPL.

Point 4 I could not extract any meaning from.

Point 5 ... I will grant you nothing in the relational world is very far along with parametric polymorphism. The significance of this fact, however, is greatly reduced by the fact that the relational algebra is itself parametrically polymorphic.

Marshall Received on Tue May 02 2006 - 16:23:18 CEST