Subject: Re: testing object inheritance
From: Vassily (vass@cs.washington.edu)
Date: Mon Nov 13 2000 - 01:47:12 PST
I have similar feelings to Jonathan's. Should be PC to test "is_foo"
where the "foo" refers to a type.
I thought that one could get away without types at runtime: the compiler
could look at all objects declared to conform to the given type or
subtype. For example, all children of "collection" class conform to type
"collection" (with the exeption of queues and stacks, which the compiler
can recognize also).
The case that's not clear how to handle, though, is conditional subtyping.
For example, is_printable(array[T]) holds only when T is printable. Which
implies that the semantics of this predicate is undefined if the program
does not typecheck (which, in case of Vortex, is essentially always).
More thinking is needed here.
Vass
On Thu, 9 Nov 2000, Jonathan Aldrich wrote:
> > This is an intentional design feature. It's consider Morally Wrong to
> > be testing the run-time inheritance of an object. You've violated its
> > abstraction. If there's something you'd like to do with an object,
> > then you define the appropriate methods on it. This can often take
> > the form of a bunch of is_foo, if_foo(true & false continuations), but
> > then the user has introduced an abstraction "foo" that is conceptually
> > unrelated to the underlying inheritance of the object. Any object can
> > claim that it is a "foo", independent of how it's implemented. Cecil
> > forces you to write these instanceof methods yourself, in order to
> > save you from the Sin of violated an object's integrity.
> >
> > Or at least that's the philosophy. Syntactic sugar might make this
> > philosophy easier to swallow.
>
> A couple of thoughts. I totally agree that it's a "sin" to test the
> inheritance of an object--this means you are depending on the
> implementation, and violating the abstraction as Craig said. However, I
> don't think it's a sin to test subtyping relationships, because a
> subtyping relationship *is* part of any object's abstraction--you could
> even argue it's the essence of the abstraction. In Cecil, types
> conceptually don't exist at run time, but this is an argument for why they
> maybe should in the design of Diesel. If you want to do any computation
> based directly on an object's abstraction, you want types at run time.
>
> A significant problem with defining methods like is_foo, if_foo, is that
> you define a lot of methods, which often duplicate things in the
> subtyping hierarchy. This is one of the problems Aspect-oriented
> programming is supposed to be good at solving...if we design a good,
> general-purpose aspect facility in Diesel, it may help with this problem
> (although I haven't thought it through).
>
> Craig suggested we read about AspectJ, and I could present in 590po. For
> various reasons, the next couple of weeks are bad for me, but December 6th
> might work. 590n people might be interested, but maybe less so than our
> group.
>
> Jonathan :-)
>
This archive was generated by hypermail 2b25 : Mon Nov 13 2000 - 01:47:18 PST