Miroslav Silovic wrote:
What bugs me is a possible duplication of functionality. I believe that declarative requirements should go on roles. And then packages could do them, like this:

package Foo does FooMultiPrototypes {

I like this idea because it makes roles the central bearer of type
information. I think there has to be a way for a role to define
constraints onto the thing it is going to be composed into---see my
unreplied mail 'class interface of roles'. The type requirements
of a role could be mostly inferred from the role definition, especially
if we have something like a super keyword that in a role generically
refers to the thing it's composed into before the role is composed.
Note that self refers to the object *after* composition and instance

Of course, I hadn't quite thought this through - as packages aren't classes, there would probably have to be heavy constraints on what FooMultiPrototypes may declare.

Basically instance data declarations and methods require a class
for composition. Everything else can also go into packages and modules.
IIRC, additional methods can come as package qualified as in

role Foo
   method Array::blahh (...) {...}  # goes into Array class

and as such require the package to make an Array class available.


Reply via email to