Re: Object-relational impedence

On Mar 9, 9:13 am, "Yagotta B. Kidding" <y..._at_mymail.com> wrote:
> S Perryman <q..._at_q.com> wrote innews:fr0hft$8gf$1_at_aioe.org:
> > Yagotta B. Kidding wrote:
> >> S Perryman <q..._at_q.com> wrote innews:fqpj0o$lke$1_at_aioe.org:
>
> > TN>In the other message
> > TN>you dismissed projection as being covered by the concept of
> > TN>subclassing.
>
> > SP>No. Projection is covered by *type substitutability* .
>
> > TN>Can you please be more specific? If we remove some [data]
> > TN>attributes, does it mean the resulting "entity" is a subclass.
>
> >>>No, merely that the resulting entity is now deemed to be of
> >>>another type, substitutable with the original type.
>
> >>>type T
> >>>{
> >>> x, y, z
> >>>}
>
> >>>Set<T> ts ;
> >>>Set< type { x, y } > ps = { e IN ts : e.x > 123 } ;
>
> >>>The elements of ps are effectively projections of the elements in ts.
>
> >> Hold on, you have a value of type Set<T> assigned to a variable of
> >> type Set<type{x,y}>.
>
> > Basic type substitutability (structural equivalence) .
> > The { x, y } type has properties in common with T (the x/y properties)
> > . Therefore the assignment is legal.
>
> > So the assignment is a projection is of a type (x,y,z) to a type (x,y)
>
> In any OO langauage I am familiar wth, you can assign a subtype value
> to a supertype variable. However, you did not establish any
> subtype/supertype relationship in your example, therefore, the
> assignment is illegal.

If the system being discussed is based on structural rather than nominal types (which he explicitly stated, although not in a very obvious way) then it is sufficient to compare the *structure* of two types to determine if one is a subtype of the other. In this case, attributes {x, y} are a subset of {x, y, z} and so a subtype relationship exists. No, this is not how Java or C++ work; OCaml maybe?

> Even when you establish such relationship, no projection really takes
> place, the information is still there, it's just hidden, as can
> easily be seen by casting back to the original subtype.

Well, this is approximately true, but it's not clear how important it is. What does it mean *logically* for a projection to "really take place?" What if the language doesn't have upcasting?

Note that we can translate Mr. Perryman's code into SQL in a fairly straightforward way and preserve all the properties he wants from his example. Which is unsurprising since SQL is structurally typed.

Marshall Received on Sun Mar 09 2008 - 19:04:16 CET