> 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
