|
|
Re: Static Behavioral Subtyping and Heron Traits
|
Posted: Jan 12, 2006 5:07 PM
|
|
> > This is correct on all fronts except for:
> >
> >
> > writeln( b.one() ); // prints 11 not 1.
> >
>
> Something is crying out in me! That is, I feel very
> surprised, and I like the principle of least surprise.
>
> Problem 1) If it is 'required' that the procedure return
> 22, this is all well and good, (at least it sounds
> reasonable to be able to restrict return values),
This is example is very confusing, that kind of code isn't a standard example and shouldn't ever be written. It doesn't restrict the behavior but instead completely overrides it. This is possible in the behavioral subtyping model of Heron, but is strongly discouraged.
> but if
> that is required it should be impossible to override with
> a function that returns anything except 22. Otherwise the
> behavioural contract is violated.
Just so I am perfectly clear:
"return 22" is actually an override of the behaviour and not part of a contract check.
trait NotAContract22 {
requires {
return22() : int {
_override; // result = _object->return22();
return 22; // ignore result, and return 22
}
}
}
If you want a contract check, it would look like:
trait Contract22 {
requires {
return22() : int {
_override; // result = _object->return22();
assert(result == 22); // postcondition check
}
}
}
Even though NotAContract22 is bizarre, it can still be useful in other circumstances.
I have managed to make everything much more confusing than it actually is, and for that I apologize. I will be posting a new article soon which goes into much more detail and hopefully clears this up.
Thanks to everyone for their comments, it is really helping me refine my message.
|
|
Previous Topic
