From: Craig Chambers (chambers@cs.washington.edu)
Date: Mon Oct 21 2002 - 10:49:31 PDT
I think you've hit on two limitations of Cecil's predicate classes, one
accidental, and one inherent.
The accidental problem is that it turns out that two separate ideas have been
conflated with predicates: the superclass(es) that the original object is an
instance of (in this case Rectangle), and any additional superclass(es) that the
object should act like having when the predicate is true (in this case Square).
There's only one list of superclasses of a predicate class now, and they're all
treated as the first kind. I.e., preconditions, not postconditions. It
wouldn't be too hard to extend the language to allow the second kind of classes
to be specified also.
The more inherent problem is that predicate subclasses can't be treated as
types. Say you wanted to have an array[Square]. You want to put in objects
that are subtypes of Square. BonaFideSquare is a subtype, so that works. But
the SquareRectangle predicate subclass of Rectangle *isn't* a subtype of Square,
even if it supports all the right square methods, because it is only
*temporarily* a square. It might at any point in the future stop being a
square, e.g. if its width but not its height were changed. If this
SquareRectangle were put into the array, then after the SquareRectangle reverted
to Rectangle, the array would contain an object that wasn't a Square, and type
safety would be violated.
There are several alternative formulations of predicate class-like things that
are somewhat more amenable to static typechecking and partially resolve these
kinds of issues, but I don't know of anything that's completely satisfactory.
-- Craig
Andrei Alexandrescu wrote:
>
> No waxing here, but Cecil is da bomb! Predicate-based inheritance is very
> powerful!
>
> There's a problem of which solution I believe can be devised with
> predicates, but I can't find it.
>
> Suppose I have the classic Shape hierarchy in a CAD program used for
> designing processors. There's a Rectangle class, a Line class and so on.
>
> Sometimes, I need to process all elements that are square. Now, there could
> be Rectangles that happen to have w = h, as well as some bona fide Square
> objects that are square by design (always). I want to iterate over both
> types in a shot and do something with them.
>
> The trick is to implement BonaFideSquare so as not to waste space; assume
> there are tons of such BonaFideSquare objects and you need to store the
> minimum information for each.
>
> So what's needed here is an object Square without data, an object
> BonaFideSquare that contains a point and an integer (origin and width), and
> another object Rectangle that contains a point and two integers (origin,
> width, height). When width = height, Rectangle should automagically inherit
> Square so it can be processed as such.
>
> What would be a solution in Cecil for that? I tried a number of approaches,
> but I couldn't find the space-saving one.
>
> Andrei
>
> _______________________________________________
> Cecil mailing list
> Cecil@cs.washington.edu
> http://majordomo.cs.washington.edu/mailman/listinfo/cecil
_______________________________________________
Cecil mailing list
Cecil@cs.washington.edu
http://majordomo.cs.washington.edu/mailman/listinfo/cecil
This archive was generated by hypermail 2.1.5 : Mon Oct 21 2002 - 10:49:36 PDT