Re: Declaring super types

On Apr 20, 4:06 am, r..._at_raampje.lan (Reinier Post) wrote:
> Keith H Duggar wrote:
>
> [...]
>
> >As you've already pointed out, conversions neither require sub/
> >super/duper typing nor do they define them. Such "inheritance"
> >notions get in the way of clear thinking far more than they help
> >(actually that's true of most hierarchal notions to begin with).
>
> By way of illustration: some time ago I needed a 100K codebase
> in VB.NET converted to C# and I found a conversion tool to do it.
> It was worth the money, but perfect it was not. Some constructs it
> refused to convert; on some constructs it produced code that wouldn't
> compile. But worst of all, occasionally it would produce code that
> compiled perfectly well, and was still wrong. For instance,
>
> 3/2
>
> was converted to, can you guess it,
>
> 3/2
>
> Wrong! These expressions do not denote the same value
> in VB.NET and C#.
>
> What is the problem here? Can we put the blame on any of the two
> languages for interpreting this expression "wrong"? I don't think so.
> I think the problem is exactly what Keith writes: just saying that
> an integer number "is a" rational number doesn't tell us all that much.
> It doesn't tell us the value of 3/2, for one thing.
>
> What we can do is pick an exact, formal definition of what "is a"
> means and apply it consistently. The results are probably going to be
> counterintuitive in some cases but at least well defined and consistent.

I agree. Note that I didn't state INTEGER isa RATIONAL. Instead   INTEGER(n) isa RATIONAL(n,1)
which embodies the very specific sense in which we regard the integers as being a subset of the rationals.
> >In other words, totally drop these notions of sub/super/duper
> >type and most if not everything is simpler and more clear. In
> >this specific case there would simply be a function signature
>
> > () : INTEGER -> RATIONAL
>
> >declared somewhere with some name or anonymous as above that
> >defines a coercion for this multi-sorted algebra. That is it.
> >No more, no less, no need for sub/super/duper thinking at all.
>
> Yes. Then again. "is a" does have a simple, useful and consistent
> definition for the relational model: for relvars R, S, we can write
>
> R is a S
>
> as a shorthand for:
>
> + all attributes of S are attributes of R;
> + those attributes are a (possibly super)key of R, and
> + R projected on those attributes is always a subset of S.
>
> This completely sidesteps any considerations on the semantics of,
> or operations on, domain values, which is what I was taught
> "the relational approach" is all about. So that is my answer
> to David's question.

That doesn't fit my notion of is-a for data types. I agree with D&D's subtype = subset. I don't think it's reasonable for implicit conversions to "slice" or "project" (i.e. drop information). Of course they shouldn't add information either. Received on Tue Apr 20 2010 - 04:29:26 CEST