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
more_foo()?
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ß)
