Re: (OT)Dynamic inheritance (was: Object support in the relational model??)

From: Dan Muller <spam_dmuller_not_at_spookydistance.com>
Date: Sun, 02 Jun 2002 15:04:01 GMT
Message-ID: <BtqK8.19936$UT.1308982_at_bgtnsc05-news.ops.worldnet.att.net>


"Rick Morris" <morriscode_at_telocity.com> wrote in message news:3cf7c6f7_7_at_nopics.sjc...
> >
> > Date & Darwen's programming model separates data and action fairly
> strictly,
> > yet still provides all the important types of polymorphism. This idea
has
> > really started to appeal to me -- the common OO inheritance models seem
to
> > bundle too many orthogonal concepts together. I'd like to see what a
> > language would turn out like if it started from D&D's Tutorial D and
added
> > good module/package features, like Modula-2 or Ada. I suspect that it
> would
> > be very flexible.
> >
>
> My only complaint about this is that it is not happening fast enough!! We
> developers who really want a rigorous implementation of the relational
> model, along with object-relational capabilities should be doing
everything
> possible to make this happen:
>
> 1. To date there has only been one attempt at an implementation of
Tutorial
> D, which is a commercial project, available only on Windows servers:
> Dataphor, at www.alphora.com (see
> http://www.pgro.uk7.net/x_trdbms_impl.htm).

Yes, I just saw that recently when Chris Date finally 'revealed' this. Fabian Pascal had been hinting at it. Unfortunately, it's unlikely that the company I work for would even consider paying the considerable licensing fees. They seem a bit high to me. Perhaps justifiable, but my company is too tight to go for this.

> 2. But, there is a SourceForge "placeholder" for discussion of a project
to
> create an open implementation of TutorialD, though:
> http://sourceforge.net/projects/tutoriald/ Let's all provide as much
support
> for this as possible.

Saw this a while ago; looks like mere wishful thinking so far.

> 3. If there is any existing database that lends itself to these endeavors,
> it would be PostgreSQL (www.postgresql.org). In the past, Date, Darwen, et
> all... have said that the Ingres database (on which PostgreSQL was based),
> was the only commercial database he saw that had any potential to be a
true
> RDBMS. At the time, Ingres used its own query language called QUEL, which
> apparently adhered much closer to the relational model than SQL. (But, of
> course, pure survival dictated that Postgres had to support SQL, thus it
> became PostgreSQL.)
>
> See
> http://searchdatabase.techtarget.com/tip/1,289483,sid13_gci788645,00.html
> and
> http://lists.xml.org/archives/xml-dev/200111/msg00338.html

Yes, PostgreSQL has been on my mind too, in this regard.

> 4. My point is that SQL flourished because of industry (and developer)
> demand. As Date, Darwen and Pascal say, the only way we will get a better
> relational database is if we provide enough demand (and support) that it
> becomes worth the while of the industry developers, and hopefully the open
> source guys such as Postgres as well.

Agreed.

One of the problems with "implementing Tutorial D" is that it is not a fully-developed general-purpose language. A fair amount of work would need to go into it yet to make it into a scalable general-purpose programming language.

I've been pursuing a different avenue within the context of my day job. I'm working on a C++ database API that is modelled on Tutorial D's concepts. C++ is flexible enough to make this interesting, although it's still hard. We already had a database API layer of our own devising to isolate and assist our application code, but it was based, AFAICT, on OODB principles.

I've got a fair amount of the relational algebra working already -- natural joins using operator&&, unions with operator||, etc. -- but I'm not at all happy with the type system yet. Because of the nature of relation types, the API has to rely entirely on dynamic typing -- I haven't figured out how, even with sophisticated template use, I could use static C++ types to represent distinct relation types, since relation types are generated by relational expressions. This limitation tends to permeate many aspects of the API. It's not a debilitating problem, however.

The syntax of relational expressions in such an approach will never be an nice and convenient as in a language like Tutorial D, but it's tolerable. Received on Sun Jun 02 2002 - 17:04:01 CEST

Original text of this message