Re: domains aren't subtypes, right?

Marshall Spight wrote:

> Hi,
>
> So, I sometimes hear this idea that you could create a new type from
> an existing type. One example I've heard is that you could declare
> a "city" type (as part of an address) that was in some way derived
> from the string type. Then you could decide what operators/functions
> this new type would "get" (inherit?) from its originating type. For example,
> you might want to compare city values for equality, or for lexical order,
> but you wouldn't meaningfully want to concatenate city values, even
> though city comes from string and string has a concat operator.
>
> Sometimes I hear this called a "domain" but that word seems heavily
> overloaded.

Domain and type are generally taken to be synonyms - I guess relational theory tends to use domain for historic reasons.

> So what is the relationship of the city type to the string type?
 > It's not a subtype.

I agree, since a subtype must have all the properties that it's supertype has.

 > Could it be a supertype?

Yes and no.

If type CITY is a supertype of type STRING then STRING is a subtype of CITY by definition.
If STRING is a subtype of CITY then all strings are cities by definition. But saying that all strings are cities doesn't really sound right.

It might be better to have a type called BASIC_STRING that doesn't have concatenation as the root string type, and make the STRING type a subtype of BASIC_STRING. You could then declare your address attribute as having type BASIC_STRING, or have CITY as a synonym (or possibly subtype) of BASIC_STRING.

 > Some other kind of relationship entirely?

In OO terminology one might say that CITY delegates to STRING.

Regards,
Kieran Elby Received on Fri May 23 2003 - 12:41:05 CEST