HaloO Jonathan, you wrote: > Of course, you then run into a problem if the class _doesn't_ redefine > method equal; if it doesn't, then what is GenPointMixin::equal > calling?
This is the reason why there is a type bound on the class that should result in a composition error when the equal method is missing. Shouldn't the 'divert' be a trait of the method instead of a key/value pair on the class? And what does your syntax mean? Looks like the key is indicating the method and the value is the namespace where method lookup starts. > And you also run into a problem if you want the class to > track the position in polar coordinates instead of rectilinear ones - > it would still represent a point conceptually, but the implementation > of method equal (at least) would need to be overridden. Oh, yes. Doing the right thing is difficult. Changing representation of the point while keeping the interface can only be done in the class. OTOH, the interface would include the rectilinear accessor methods. And these are called in the equal method. Thus a class doing the GenPoint role correctly needs to provide .x and .y methods even if they aren't simple auto-generated accessors of attributes. But note that these two are not going through the superclass interface but the self type. In the case of the equal method the dispatch slot contains the role's closure which calls into the class' closure. There is no dispatch to the role because the role is flattened out in the composition process. It is interesting to think of another PolarPoint role that also has an equal method that would conflict with the GenPoint one. Then the class has to disambiguate. Which in turn requires the class to provide an equal method that overrides both role versions. Note that I think the conflict detection of role methods prevents the composition of the equal method through the superclass interface. I admit that this warps the meaning of the class' equal method from beeing an aspect in the role's method to the definer of the method. This can be a source of subtle bugs. That is the class composer can't distinguish an aspect method from a disambiguation one unless we introduce e.g. an 'is disambig' trait. And e.g. an 'is override' trait when the class designer wishes to replace a role method even if there's no conflict. > A cleaner solution would be to define a private helper method which > the role then demands that the class override. This is _very_ similar > to the solution that you described as "clumsy" a few posts back, with > the main difference being that the helper method, being private, can't > be called outside of the class. To me, the only clumsiness of this > solution comes directly from the cluminess of the overall example, and > I consider your proposed alternative to be equally clumsy - it merely > trades one set of problems for another. There's a lot of truth in that. But I don't consider the example as clumsy. It is an important issue that arises whenever method recombination is needed to deal with the guarantees that the role as a type makes. Calculation of a type bound on the class that has to be met in the composition is a strong tool. >> And yes, in Perl 6 the method isn't called equal but eqv or === and >> has a default implementation that retrieves the .WHICH of both args. > > What inspired that comment? Sorry, I didn't want to intimidate you. But I wanted to prevent comments that choosing a method equal is not the right approach and MMD should be used instead. But I think all of what we discussed so far stays valid if the equal method is a multi. IIRC there is just one namespace slot for the short name. And we are discussing how this slot is filled in the class composition process. BTW, why have you gone off-list? Regards, TSa. --
