Re: O'Reilly interview with Date

From: erk <eric.kaun_at_gmail.com>
Date: 9 Aug 2005 11:10:46 -0700
Message-ID: <1123611045.988668.221200_at_g49g2000cwa.googlegroups.com>


Kenneth Downs wrote:
> This makes the RM semi-structured :)
>
> To the RM, a table is semi-structured because an item of type char(20) is
> handled as payload, an opaque stream of bytes. The type engine provides
> services such as comparisons, but the Relational engine doesn't care.

Heh, interesting point.

There are possibly a couple of overlapping concepts here. This is unwashed train-of-thought only, so beware; I've just had a large coffee.

  1. The difference between "application" and "framework" might be whether the contents of one or more containers are relevant to processing.
  2. Then again, this may simply be a function of level of abstraction. In many O-O apps, you pass objects around without using all of their attributes and methods. Subsequent "downstream" code access those (much like the "downstream" filters in the packet-handler actually interpret the bytes).
  3. With most quasi-relational apps, access to the data is explicit (no "SELECT *" allowed in sane apps), and thus you don't swallow the "encapsulation" red herring (which I'd say is more applicable in "frameworks" than in "applications"). However, one can certainly conceive of a relational "framework" that shuttles relations around without (fully) interpreting their types.
  4. Also in O-O apps, instances are passed through layers with no reference to their run-time types; for example, a Java ArrayList punted about through formal parameters typed as "List" or "Collection". In configuration/table-driven designs, often these will be "interpreted" by plug-in code that checks their types and activates a given method if it's a PointyHairedBoss rather than just any old Employee.

So is "semi-structured" really any different than simply referring to a value as an instance of a supertype rather than its run-time type (e.g. the array of bytes is treated as such, rather than bytes-which-encode-a-naughty-JPG)? Is this all any different than layers of abstraction, some of which I'd loosely term "framework layers" and others one might call "business layers"?

Sorry for the fluffy ramble.

  • erk
Received on Tue Aug 09 2005 - 20:10:46 CEST

Original text of this message