--- On Wed, 14/10/09, Jon Lang <datawea...@gmail.com> wrote:
> From: Jon Lang <datawea...@gmail.com>
> The initial possibility that springs to mind would be to
> use longnames
> to disambiguate between the two options - specifically, by
> means of
> the invocant:
>
> role T1 { method foo() }
> role T2 { method foo() }
> class C does T1 does T2 {
> method foo(T1 $self:) {
> $self.T1::foo() }
> method foo(T2 $self:) {
> $self.T2::foo() }
> }
>
> ...or something to that effect. You'd still have a
> disambiguation
> issue, in that you'd somehow need to specify which "hat" an
> object of
> class C is wearing when you try to call the method.
Except that if a consumer of C needs foo(), they have to fully qualify the call
to foo(). That violates encapsulation.
> Much of this could be handled implicitly, by means of which
> role was
> requested when the object was passed into the current
> block:
>
> sub bar (T1 $x) { ... }
> sub baz (T2 $x) { ... }
> my C $x;
>
> bar $x;
Same problem as above. Works for C, but not for consumers of C which need to
call foo().
> In other cases, there may be no way to implicitly
> disambiguate. In
> those cases, there would need to be an explicit way to
> decide which
> hat the object is wearing.
I really don't think that deferring the decision works. The "freezing"
technique described in the paper allows the consumer, C, to statically bind the
method foo() in the methods in the appropriate role which call it. Dynamic
binding defers the decision which causes implementation details to leak to
consumers of C. This means that if you change your roles, your consumers will
potentially need to be rewritten.
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog - http://use.perl.org/~Ovid/journal/
Twitter - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
