Re: Two meanings of "data structures"

From: Marshall Spight <mspight_at_dnai.com>
Date: Tue, 16 Nov 2004 16:36:32 GMT
Message-ID: <k0qmd.39434$V41.25106_at_attbi_s52>


"erk" <eric.kaun_at_pnc.com> wrote in message news:1100614593.204840.208210_at_c13g2000cwb.googlegroups.com...

>

> This is not to say that the "primitive structures" have no place; I
> just feel that in most of the programming I do, relations would trump
> them all.

Yes yes! Somewhat humorously, I see those primitive data structures as only being useful in implementing relational engines! I absolutely agree that in the vast majority of application programming that I do, "relations would trump them all."

> As far as "drop-in" goes, unless you're talking about dropping in new
> types (domains) and then using them in relations, it's not really
> applicable.

Okay, let's say I have some application-level tree I'm defining. Maybe an org chart. (The canonical critique at this point is to say trees don't happen all that often and an org chart isn't a tree. Feel free not to respond if that's all you're going to say; I've already heard it.) I can in OOPLs just declare a collection as a Tree and it immediately has only the right methods and is also immediately self-documenting how it structured. Not so with relations; we may embed an adjacency list in a relation, but this is not as obvious when looking at the code. Also, lots of possibly undesired operations are now supported.

If we want a relation to represent, say, a queue, we need to enter a bunch of transition constraints that again will not be obvious in intent. In some ways the OOPL techinque of encapsulating *functionality* is superior to the RM approach, at least as I understand it. (The canonical comment at this point is to say "then you just don't understand it very well" and leave it at that. If the responder is not going to add to my understanding, please feel free not to respond; heard it!) (These parentheticals are explicitly *not* addressed to Eric.)

So it seems to me that perhaps we should discard OOPLs encapsulation of data in favor of the RM approach and declarative integrity constraints; but perhaps also we should examine the OOPL technique of collecting up appropriate operators as a style of constraint enforcement and see what we can't learn.

Marshall Received on Tue Nov 16 2004 - 17:36:32 CET

Original text of this message