develooper Front page | perl.perl6.language | Postings from September 2006

Re: RFC: multi assertions/prototypes: a step toward programming bycontract

Thread Previous | Thread Next
From:
Trey Harris
Date:
September 28, 2006 23:30
Subject:
Re: RFC: multi assertions/prototypes: a step toward programming bycontract
Message ID:
20060928224916.X87014@bowser.eecs.harvard.edu
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

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About