In a message dated Thu, 28 Sep 2006, Aaron Sherman writes:
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) { ... } }
One thing that occurs to me: following this "contract" or "promise"
analogy, what does C<...> mean in a role or class?
Unless I've missed somewhere in the Synopses that explicates C<...>
differently in this context, yada-yada-yada is just code that "complains
bitterly (by calling C<fail>) if it is ever executed". So that's fine for
an abstract routine at runtime--code calls it, and if it hasn't been
reimplemented, it fails.
But unless something else is going on with C<...>, as far as the language
is concerned, a routine with body C< {... }> *is* implemented, as surely
as a routine with body C<{ fail }> is implemented. So the routine is only
"abstract" insofar as you'll need to reimplement it to do anything useful
with it.
Roles are types, and we've been talking about doing a role as making a
promise. But "does" just mixes in the role, implementations and all. If
your yada'ed routine ever gets *called*, you fail, so it would behoove you
to implement any role you do, unless you're writing an abstract class on
purpose.
But as we have no "abstract" adverb presently, it seems to me that the
compiler has no way of inferring whether a give nclass doing a role
actually has implemented what it's supposed to in order to meet the role's
specification or not. We only find out if the contract was not met or the
promise was not kept at runtime.
Is my inference correct?
Trey