There seems to be some confusion about which way up the world is.
On Tue, Mar 11, 2003 at 01:25:41PM +1100, Damian Conway wrote:
> Which in turn is because:
>
> not Scalar.isa(int)
On Thu, Mar 13, 2003 at 11:55:06AM -0800, Larry Wall wrote:
> On Thu, Mar 13, 2003 at 11:31:30AM -0800, Austin Hastings wrote:
> : "Everyone Knows" that an Int is a Scalar, and therefore a sub that has
> : a Scalar parameter can safely be passed an Int. This is normal.
> I don't see a problem. Scalar == Int|Num|Str|Ref, so Scalar.isa("Int").
>
> Larry
On Thu, Mar 13, 2003 at 12:00:54PM -0800, Paul wrote:
> > I don't see a problem. Scalar == Int|Num|Str|Ref, so
> > Scalar.isa("Int").
>
> Scalar.isa("Int") && Int.isa("Scalar") ????
This term "subtyping" I didn't know:
On Fri, Mar 14, 2003 at 10:46:31AM -0800, Larry Wall wrote:
> Well, I'm using the terms type and class pretty much interchangeably
> there, so don't put too much weight on that. But Perl 6 may well
> distinguish classes from types. Classical classes can only add
> capabilities when you derive (yes, you can redefine methods to do less,
> but the interface is still there). When I think of types, I'm thinking
> of parameterizing a class with some constraints. In the Ada world,
> that's called "subtyping". Whether these contraints are mathematical
> ("must be an even number") or structural ("must have dimensions
> (3,3,3)"), they still cut down on the allowed set of values for the
> base type.
I'm not sure if it helps people understand why I'm confused by explaining
my background, but I've done exactly zero computer science, and have come
to whatever (mis)understanding of OO I have by using C++ (and then perl).
I've never used Java, but I'm aware that it has a concept of "interfaces"
that can cleanly fulfil most of what C++ programmers end up using multiple
inheritance for.
Back to perl:
I admit that I think of Scalar as being something that conceptually
multiply inherits from String, Num, Int and "other" (ref), because a scalar
can be any of these things as it feels necessary. Being from somewhat a C++
background (oh, and knowing how SVs work in perl5's source), I don't really
feel that the tree goes the other way, with Scalar at the top. I don't
expect Int to have a (in perl5-speak) .= method, but if Int inherits from
Scalar, it's going to have to, isn't it?
This reminds me of a conundrum that was explained to me - sub-classing
geometry:
Presumably a Circle class has an attribute radius, which can be set and
retrieved. And Ellipse has two, semi-major axis and semi-minor axis.
A circle is an ellipse where the semi-major and semi-minor axes are equal.
So, if you implement Circle as a subclass of Ellipse this is fine - Circle
provides the radius methods, so there's no way an Ellipse can have one called
on it. Good. And if you call Ellipse's semi-major axis method on a Circle
you get back the same value as radius (or semi-minor axis)
But what happens if take a Circle (isa Ellipse) and try to set the semi-major
axis to a value that differs from the semi-minor axis? (I don't know. It
violates something as I understand it)
Conversely, if you implement Ellipse as a subclass of Circle, this problem is
solved. There are no semi-major or semi-minor axes methods, so no chance of
going wrong there. But as Ellipse isa Circle, it will inherit Circle's radius
method. What should it return the radius of an Ellipse? (I don't know)
I don't know the answer to which way up they go. As I understand it, there
is no right answer.
Likewise I'm not convinced about which way round the scalar types heirachy
goes in perl6. I like it to be both ways up at the same time.
(in the same universe please)
Then again, this week is the subroutines apocalypse, not the objects
apocalypse, so hopefully all will become clear in a subsequent this week.
Nicholas Clark
