Re: Role Method Conflicts and Disambiguation (Theory-theoretic take)

Here's how I see roles.  This is just an attempt to formalize our
concepts so that the answer becomes an obvious truth rather than a
decision.

A role is an interface with some default implementations.  Here's an exampl=
e:

role Foo {
# anything that conforms to Foo must provide a foo() method
# if one is not provided, this body is used instead
method foo () { say "hi" }

# anything that conforms to Foo must provide a bar() method
# if one is not provided, then there is an error
method bar () {...}

# anything that conforms to Foo must provide a baz() method
# if one is not provided, then an instance variable is used instead
has $.baz;
}

role Bar {
# anything that conforms to Bar must provide a bar() method
method bar() {...}
}

# this is a conditional: anything that conforms to FooBar also
# conforms to Foo and Bar
role FooBar {
does Foo;
does Bar;

# the requirement for the implementation of a bar() method is
# carried over[1]
}

This is a sort of suspension.  If you ignore the roles Foo and Bar,
you have simply a role FooBar that has three requirements: foo(),
bar(), and baz(), where foo() and baz() have defaults.  When you
compose this into an empty class, you will get not a conflict but a
missing method error.  bar() was not implemented.

Now, let's say that bar() was given a default implementation in Foo.=20
Then FooBar would be a fully-defined role with no requirements.

Let's say that bar() was given a default implementation in both Foo
and Bar.  That's a conflict.  But let's follow suit and pretend that
Foo and Bar didn't exist.  If you try to compose in FooBar, you will
get an ambiguity, which can be resolved by defining your own bar().=20
So clearly, FooBar simply has a required foo() again.

To summarize, as we'll use this later:

Foo:    foo() default, bar() default, baz() default
Bar:    bar() default
FooBar: bar() required

So then we take that, and say that we can give a default
implementation for this now-required method.  FooBar may disambiguate.

Moving on.

role Baz {
does Bar;
}

By my free-derivation (or composition in this case, I guess)
principle, Baz is now equivalent to Foo.  If you think of them as
interfaces, it makes perfect sense.  Baz provides no additional
implementations, nor imposes any additional requirements, and thus you
must do precisely the same things to conform to Baz as to Foo.

Baz: bar() default

Now:

class MyClass does FooBar does Baz { }

Here's where the theory proposal comes in, yet again.  The definition
of a class is just the definition of a role together with a
(syntactically impossible) declaration of a concrete type.   Creating
the class is erroneous if the role is not fully-defined.  So let's
just look at the role half:

role MyClass {
does FooBar;
does Baz;
}

Now we ignore the inner workings of FooBar and Baz.  This is a good
idea, as it lets us refactor freely, as long as it looks the same from
the outside.  Recall that we had:

Baz:     bar() default
FooBar:  bar() required

So clearly Baz fulfills FooBar's requirements, and MyClass is a
fully-defined role.

Okay, how did that happen?  What was the formality that we actually used?

It was the fact that at each stage of the game, we summarized the
defaults and requirements for each role, ignoring the internal makeup
(i.e., what roles were composed into it, etc.).

And it sounds correct to me.

Luke

[1] Perhaps we even require declaration.  We probably shouldn't, in
the name of keeping Perl Perl.  Any good documentation system ought to
catalog all the dependencies.

On 29/10/05, Luke Palmer <lrpalmer@gmail.com> wrote:
> Moving on.
>
>     role Baz {
>         does Bar;
>     }
>
> By my free-derivation (or composition in this case, I guess)
> principle, Baz is now equivalent to Foo.  If you think of them as
> interfaces, it makes perfect sense.  Baz provides no additional
> implementations, nor imposes any additional requirements, and thus you
> must do precisely the same things to conform to Baz as to Foo.
>
>     Baz: bar() default

You meant to write 'equivalent to Bar', not Foo, right?


Stuart

On 10/28/05, Luke Palmer <lrpalmer@gmail.com> wrote:
> Here's how I see roles.  This is just an attempt to formalize our
> concepts so that the answer becomes an obvious truth rather than a
> decision.
>
> A role is an interface with some default implementations.

-snip-

> Now we ignore the inner workings of FooBar and Baz.  This is a good
> idea, as it lets us refactor freely, as long as it looks the same from
> the outside.

I would say that this isn't just a good idea; it's at the core of what
distinguishes composition from inheritance.  With classes and
inheritance, you keep all of the baggage that accumulates at each
step, on the off-chance that some as-yet unknown descendant might need
it.  With composition the only baggage that a role keeps is the
baggage that is directly relevant to itself.  Whatever gets tossed
aside can be composed in separately later on if it's needed.

> Recall that we had:
>
>     Baz:     bar() default
>     FooBar:  bar() required
>
> So clearly Baz fulfills FooBar's requirements, and MyClass is a
> fully-defined role.
>
> Okay, how did that happen?  What was the formality that we actually used?
>
> It was the fact that at each stage of the game, we summarized the
> defaults and requirements for each role, ignoring the internal makeup
> (i.e., what roles were composed into it, etc.).
>
> And it sounds correct to me.

Me, too.

--
Jonathan "Dataweaver" Lang

On 10/28/05, Luke Palmer <lrpalmer@gmail.com> wrote:
[snip]
> It was the fact that at each stage of the game, we summarized the
> defaults and requirements for each role, ignoring the internal makeup
> (i.e., what roles were composed into it, etc.).

So, in theory, one should be able to ask any given role "What do you
provide?" as well as "What do you require?". (I'm not saying that the
syntax should be available, but that the information to answer those
questions should be easily calculable.)

One concern I have is that I would like to believe that a role is a
"group of related behaviors that provides a functionality." So, if Foo
does roleA and I as the user of Foo asks "Do you do roleA?" and it
replies "Yes," then I can make some assumptions about Foo's
functionality. Otherwise, this devolves into interfaces. Interfaces
suck, especially given as they're limited to naming.

Now, if we were to say that all roles, by default, provide
multimethods, then conflicts only occur for methods that have
identical dispatching semantics. At that point, it's truly a conflict
and would need to be resolved by the composer (whether that's a role
or a class).

Now, it's obvious why a class would have to resolve that conflict. I
would say that a role would have to resolve the conflict is that a
role should present a consistent API to the rest of the world. In
other words, I want to be able to depend on the fact that classA does
roleAB means something in terms of the functionality that classA
provides to me. I don't want it to be a glorified can() check. That
does no-one any good.

Rob

Rob Kinyon wrote:
> Now, it's obvious why a class would have to resolve that conflict. I
> would say that a role would have to resolve the conflict is that a
> role should present a consistent API to the rest of the world. In
> other words, I want to be able to depend on the fact that classA does
> roleAB means something in terms of the functionality that classA
> provides to me. I don't want it to be a glorified can() check. That
> does no-one any good.

Well, yes and no.  I like the ability for default behavior to be
passed along through composition; OTOH, I don't want to be forced to
require that role A's default behavior will appear in role AB.  To me,
that sort of thing is what classes and inheritance are for.

That said, roles differ from interfaces in that roles _can_ have
default behavior associated with them - whereas interfaces really are
nothing more than glorified can() checks.

Think of it this way: with inheritance, every class has to be aware of
its full lineage, as family connections are very important.  With
composition, the only family connections that are at all important are
that descendants look like their ancestors.

--
Jonathan "Dataweaver" Lang

On 10/28/05, Rob Kinyon <rob.kinyon@gmail.com> wrote:
> Now, it's obvious why a class would have to resolve that conflict. I
> would say that a role would have to resolve the conflict is that a
> role should present a consistent API to the rest of the world. In
> other words, I want to be able to depend on the fact that classA does
> roleAB means something in terms of the functionality that classA
> provides to me. I don't want it to be a glorified can() check. That
> does no-one any good.

Most certainly.  Implicit in a role or a theory is its algebra (though
we've talked about QuickCheckish ways to make it explicit).   For
instance, technically the VectorSpace theory only requires you to
define identity, addition, and scalar multiplication.  However, in
order to honestly do VectorSpace, addition has to be commutative,
which is something that the compiler usually is not able to check.

And that's why you have to explicitly say that your class "does" the
role, rather than it just inferring that from the methods you provide.
You may have named your methods the same, but there's no guarantee
that you obey the role's algebra.  By saying that your class "does"
the role, you are promising that these methods do indeed obey the
necessary algebra.

So in a way, it's a kind of glorified can().  But in another way, it
does guarante certain kinds of behavior from the implementing objects.
If you do a role and override a method that violates what the role is
supposed to guarantee, then you don't really do that role, even though
you do as far as the compiler knows.   It's a conceptual contract, not
a computationally rigorous one.

On the computational level, a role is little more than an interface
with defaults.

Luke

Luke,

On Oct 28, 2005, at 9:44 PM, Luke Palmer wrote:
> It was the fact that at each stage of the game, we summarized the
> defaults and requirements for each role, ignoring the internal makeup
> (i.e., what roles were composed into it, etc.).

This then imposes somewhat of an ordering with role composition. The
role tree will need to be traversed breadth first, and conflicts/
requirements resolved on a level by level basis.

> And it sounds correct to me.

It sounds "correct" to me as well (in theory,.. get it ,... in
theory :P).

However, I do worry about how it will work out in practice. Part of
the goal of roles (and I have been preaching this one since the
hackathon) is that they are easier to use than multiple inheritance,
have fewer headaches than mix-ins and are more useful than
interfaces. Imposing ordering as described above may make things
easier, or it may make things harder, only time and experience will
tell. I am going to give this some more thought over the wend, and
see what I come up with.

Stevan