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

Reply via email to