Jonathan Lang wrote:
Aaron Sherman wrote:
Jonathan Lang wrote:
> Actually, it's a promise made by a package (not a class) to meet the
> specification given by a role (which can, and in this case probably
> does, reside in a separate file - quite likely one heavily laced with
> POD).
That's a fine thing to want to do. Not something that I was thinking of
initially, and only tangentially related, but a good idea. I think you
get this for free by embedding a proto (or perhaps a "sigform") inside
of a role:
role Foo { sigform bar($baz) { ... } }
What would be the difference between this and
role Foo { sub bar($baz) { ... } }
This would define a non-multi subroutine with a yadda body. Later
declarations of a multi sub by the same name would be resolved as per
the rules in, I think, A12, but don't quote me on that, as I'm probably
wrong about the location. Multi and single dispatch have rules of
engagement, but essentially don't interact much until something gets
invoked.
Still, that has little or nothing to do with constraining the definition
of multi subs by signature, which is what I was proposing.
Notice the lack of export which forces this to only apply to the class
or module to which the role is applied via composition, not to a module
which imports that class or module.
True enough. That said, it wouldn't be hard to change this. Consider
the possibility of an "exported" trait, which causes whatever it's
applied to to be exported whenever a module imports its package.
The original example was an exported version, so there's no change to
make. I only gave the non-exported version as an example in this recent
mail to demonstrate that the rather unrelated concept that you brought
up (defining a role that restricts multi method definitions WITHIN a
class/module/package) just happened to be easy to do given the RFC as I
proposed it, even though I had not thought about that use before.
Please, feel free to re-read the RFC. I'm getting the impression that it
wasn't as clear, as perhaps I had intended, and you might be able to
propose some clarification....
