On 2009-Oct-14, at 8:52 am, Ovid wrote:
--- On Wed, 14/10/09, Jon Lang <datawea...@gmail.com> wrote:
The initial possibility that springs to mind would be to use longnames to disambiguate between the two options - specifically, by means of the invocant: ...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.

Good, that's what I was looking for the last time this came up. (http://www.nntp.perl.org/group/perl.perl6.language/2009/07/msg32164.html )

Except that if a consumer of C needs foo(), they have to fully qualify the call to foo(). That violates encapsulation.

I don't see that as an encapsulation problem. A leaky encapsulation means we have to know how something works, but when I have to distinguish between $dogwood.Dog::bark and $dogwood.Tree::bark, I'm distinguishing between two wholly unrelated actions (that they happen to have some of the same letters in their names is completely coincidental). So I have to know *what* a Dogwood object does; but I still don't have to know how it does it.

Or to look at it the other way around: Since we refer to things by name, those names have to be unique everywhere; so let's start out with long, "fully-qualified" names everywhere: $dog.Dog::bark(), $tree.Tree::bark(), $i.Int::succ, etc. Now everything's fine -- except that our fingers are getting tired from all that typing. We want to use shortcuts to say things like $dog.bark, because there's only one place that $dog can legitimately find a bark() method, and that's in the Dog class, so both we and Perl can easily figure out what is meant.

On the other hand, $dogwood.Dog::bark cannot be simplified by leaving out the "Dog::" because then it would be ambiguous. But if we look at it as starting with full names everywhere, and seeing what we can leave out (rather that starting with short names and having to add stuff in), I think it's not surprising.

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.

The problem with "freezing" some methods into private ones is that those methods weren't meant to be private; if my role provides a .bark method, I need to be able to 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.

But if you merely change the implementation of how bark() works (either one), nothing needs to be rewritten. If you want to change from Tree::bark-ing to Dog::bark-ing, then you *should* be rewriting code, because you're completely changing what is going on, no less than if you changed from bark()ing to fetch()ing.


Reply via email to