> Nick -- > > I've been thinking of it like this: > > class int isa intlike; # and isa value or whatever > class Int isa intlike; # and isa Object or whatever > > class num isa numlike; # and isa value or whatever > class Num isa numlike; # and isa Object or whatever > > ... > > class Scalar isa intlike, numlike, ...; # and isa Object or whatever > > The *like classes are placeholder (interface) classes that capture > the ability to *treat as* (as opposed to *really is*). And (importantly > IMO) the *like classes capture the aspects of foo and Foo that > are the same, leaving the foo and Foo classes to capture the > differences.
This is an interesting concept. We can have Intlike and Numlike abstract class that Int and Num concretify :). Then anything can derive from Intlike and Numlike and be substituted where they are expected everywhere. But this will be a common enough operation (behaving like a superclass but not actually being one) that there might as well be more intrinsic support for it: class myInt is interfaced(Int) {...} myInt must override all of Int's methods, and it inherits none of its data. It might even register in the inheritance heirarchy. I don't have enough experience with this technique to know whether or not it should. That would be a neat way to do interfaces: allow a concrete type to act as an interface. It would also be a neat way to do Scalar. Hmmm.... Luke