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

In article <2IidnapYsdljq1bfRVn-iw_at_comcast.com>, boston103_at_hotmail.com says...
> >> y.f=3.14;

Can you refer to y's i or c value?

Let me speculate: Your union type is the union of the int, float and char domains (domains being sets of values). Let's make the reasonable assumption that they are disjoint, even though a case could be made that (e.g.) 2 == 2.0 (and that C consider characters and integers pretty interchangeable). In that case, a value of the my_data type could be *either* an int, a char or a float, but not more than one at a time. Trying to treat it as a char if it is a float, leads to a (run-time?) error.

In contrast, a TTM domain with possreps has in internal representation that we don't care about. It has one or more possible representations that are always valid, no matter what the value is. This probably necessitates a 1:1 mapping between the internal representation and each possrep, though I can't recall having seen this spelled out explicitly in TTM. In any case, the domain is *not* a subtype of its internal representation---Temperature is not a "narrowing" of double. It is encapsulated. We can change the internal representation without impacting the rest of the world. We can add possreps without breaking existing code. Your union type can't do that. It's the magic of OO. :)

> That's called cheating ;) In Java, you're just narrow the single double
> datatype by defining accessor/mutator functions on the double d.t..

No, I don't. I am defining a brand new datatype (class). I am hiding its internal representation by declaring it private. I have only used doubles for possreps, because that was most convenient. I could have used a String, e.g.

String getKelvinString() { return Double.toString(getKelvin()) + " K"; }

(Note, however, that my Java example is not entirely correct, because a Java Temperature object is a variable, not a value. I also haven't considered domain constraints (e.g. no temperature can be below 0 K). But that does not impact our discussion much.)

> This is
> different from the possrep example where you define multiple possreps using
> different data types in a way identical to the union type.

What possrep example?

> The ability to say i=14 or i=0xE has got nothing to do with union data
> types.

My point exactly! But it has very much to do with possreps. You can represent an integer in decimal, or hex, or oct, or binary. Different ways of denoting the very same value.

> In both cases you assign an integer constant to an integer data type.

I'd say you assign an integer value to an integer variable. I'm nitpicky. :)  

> How is it even relevant to the issue of types?

It is a demonstration that possrep is a useful concept, that dates from before Date. So why not apply it to *all* types? A temperature is a temperature, be it measured in F, K or C. A point is a point, be it polar or cartesian. A distance is a distance, be it measured in lightyears, feet, meters or ångstrøm. An int is an int. 14 == 0xE && 0°C == 273.15 K.

-- 
Jon