On Monday, March 17, 2003, at 10:35 AM, Luke Palmer wrote:
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.
Not quite sure I understand -- how does this interact with the goal of flexibility between things which take an C<Int> vs. an C<int>, for example? Ideally...
sub foo(int $n) {...} # accepts int only (?)
sub foo(Int $n) {...} # accepts int, Int (?)
sub foo(num $n) {...} # accepts int, num (?)
sub foo(Num $n) {...} # accepts int, Int, num, Num (?)(Assuming a significant difference between int/Int and num/Num is that the latters are allowed to be undef, thus making the above distinctions more relevant)
You certainly don't want to have to type things as
sub foo(intlike $n) {...}
just to get the above flexibility, for example.
?
MikeL
