Michael G Schwern:
> Michael G Schwern wrote:
> > I see us already smashing too many things into the
> > method signature as it is. It will rapidly get
> > messy if you have a method with a complex signature
> > and a handful of attributes and preconditions.
>
> I think I have my own counter example.
>
> Consider defining an abstract class with an interface
> and I want to put some conditions onto an abstract
> method.
>
> class Abstract::Human is interface {
> attr head, shoulders, knees, toes;
> invar { .head == 1 }
> invar { .shoulders == .knees == .toes == 2 }
>
> method eat ($food) is pre { !$food.isa('Poison') }
> is post { .return eq 'Burp' }
> }
>
> since I have no method body for eat() I have no choice but to
> hang it off the signature as an attribute.
That wasn't the way I remembered it from Apoc 4... The following example is
not in A4, but its what I inferred from it...
Class Foo {
method eat($food) is abstract {
PRE { ... }
POST { ... }
}
}
Class Bar is Foo {
method eat {
PRE { ... }
... implementation ...
POST { ... }
}
}
'eat' may be an abstract method inherited by Bar from Foo... but the PRE and
POST conditions are still inherited. Though I can see the issue that
abstract precludes an implementation. But does that also require use to
preclude the code block?
Also if you rely on attributes to hang conditions... you're ruling out the
ability to reference things in the lexical context of the code block.
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com [EMAIL PROTECTED]
