HaloO chromatic,

you wrote:
Have I mentioned before that I think you should be able to say:

class Foo
        method foo { ... }
        method more_foo { ... }

class Bar does Foo
        method foo { ... }

... probably get a compile-time error that Bar doesn't support

We've discussed that when I was ranting about the type lattice
and co- and contravariance...

I'm not sure what my position back then was but now I agree
because I see CLASS as a subtype of ROLE. The only problem
is that $Larry said that he doesn't want parametric classes.

I see a reason to differentiate between roles and classes on the metalevel, but the argument is not as strong on the user-level.

I go further to see little reason to distinguish between role, class,
and type names (and what reason there is is for introspective
capabilities, not standard user-level type checking).

I strongly agree. They should share the same namespace. Since
code objects constitute types they also share this namespace.
This means that any two lines of

class   Foo {...}
role    Foo {...}
sub     Foo {...}
method  Foo {...}
subtype Foo of Any where {...}

in the same scope should be a simple redefinition/redeclaration error.
OK, sub and method can escape from this fate by means of the keyword
multi and different sigs.

Since sigils somehow define references &Foo could mean e.g. a classref
while ::Foo could be a Code type. If we then also promote . to a primary
sigil for Method... hmm have to think about that!
TSa (Thomas Sandlaß)

Reply via email to