Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]

From: vc <boston103_at_hotmail.com>
Date: 11 Jul 2005 10:35:15 -0700
Message-ID: <1121103315.842539.184290_at_g14g2000cwa.googlegroups.com>


Jon Heggland wrote:
> In article <1121096876.229888.299700_at_g49g2000cwa.googlegroups.com>,
> boston103_at_hotmail.com says...
> > I found an article by H.Darwen (
> > http://web.onetel.com/~hughdarwen/TheThirdManifesto/taamoti.paper.pdf )
> > that clarifies the issue a bit. Apparently, the kind of user defined
> > types T.T.M uses is more of object-oriented (Java, etc) than functional
> > flavour (ML, etc).
>
> Yes, hence my Java temperature example. :)

Sorry, I forgot to acknowledge that you've been trying to push me towards the object types from the very beginning.

>
> > Why not use the vocabulary familiar to many OO programmers
> > and talk about constructors and accessors/modifiers directly ?
>
> I'd guess because they think the existing OO terminology is confused,
> and want to separate more cleanly between values and variables (and
> preferrably not use the "O" word:). A "constructor" is arguably
> different from a "selector", even though it fills a similar role. Same
> thing with a "modifier" and an "update operator", perhaps.

Would not you agree that the word "constructor" describes better what it does than a "selector" ? Also, with the object type that's its procedural nature that's emphasized, in other words the only things exposed are functions exposed via an interface (or its equivalent) and the structure the functions operate on is secondary. There is some set somewhere but we sort of do not care much about it (as opposed to the functional approach with its user defined types). That's why I think the talk about values and especially the nebulous possible representations is confusing, but it's a matter of taste/style, I guess, not substance (which is not easy to discern due to the confusing syntax).

>
> > [the point] I was under impression that you wanted to compare
> > TEMPERATURE with RATIONAL without mapping temperature -> rational
> > first, that's all.
>
> Hm. I can't recall that I did, but no matter.

Sorry, probably it was me who got confused.

>
> > Overall, it was a useful discussion. Now it appears to be quite clear
> > that T.D uses types similar to Java "interface types" using nominal
> > subtyping (by name rather than by structure). Whether relying on
> > "object types" with inheritance and subtyping is preferable to
> > functional/algebraic types is yet to be determined ;)
>
> I guess. I won't go into that, at least not before I've learnt more
> about functional programming. :)

I was not suggesting we did ;)

Thanks.

vc

> --
> Jon
Received on Mon Jul 11 2005 - 19:35:15 CEST

Original text of this message