On 11/2/05, Jonathan Lang <[EMAIL PROTECTED]> wrote:
> Let's say you have this:
>
>   role A {method foo() { code1; } }
>   role B {method foo() { code2; } }
>   role C does A does B {
>     method foo() { A::foo(); }
>     method bar() { B::foo(); }
>   }
>
> Should the following be valid?
>
>   role D does C { method foo() { B::foo(); } }
>
> IMHO, it shouldn't, because D doesn't do B.

Of course it should.  To me, "role D does C" says, not "anything that
does D must do C", but "anything that does D does C".

It makes sense if you think of them as interfaces.  Say you have a
role Complexifiable (that is, this thing can behave like a complex
number).  Then you have:

    role Numifiable does Complexifiable {
        ...
    }

Complexifiable is just an abstraction that is used rarely; most things
will implement Numifiable.  But if you can behave like a real number,
certainly you can behave like a complex number.  But you don't want
people to have to say:

    class Foo {
        does Complexifiable;  # wtf?  what does that mean
        does Numifiable;
        ...
    }

Haskell makes a distinction between the two cases we're talking about here:

    -- You need to be Complexifiable before you can be Numifiable
    class (Complexifiable a) => Numifiable a where
        ...

    -- Anything that is Numifiable is also Complexifiable
    --  (by these rules):
    instance Numifiable a => Complexifiable a where
        ...

To me, "does" is much more like the latter.  Maybe we have constraints
on roles that can do the former[1]:

    role Numifiable {
        where Complexifiable;
        ...
    }

Or maybe we don't, and if you need them to implement Complexifiable
first, you just leave some methods undefined that they have to define
themselves, thus completing the interface.  I was always annoyed at
Haskell because I had to define an instance of Eq before I could
define an instance of Ord, even though Ord's algebra implies that I
can compare things for equality (and especially, since Ord defines a
total order, that a <= b and b <= a implies a = b, so it could have
implemented that for me).

It kind of seems like a Perlish thing to do to blur the two behaviors
together.

Luke

[1] Which is just this theory, without any extensions:

    theory Numifiable{^T} <= Complexifiable{^T} {
        ...
    }

So it would just be sugar in any case.

Reply via email to