The Artima Developer Community
Sponsored Link

Weblogs Forum
Static Behavioral Subtyping and Heron Traits

17 replies on 2 pages. Most recent reply: Jan 13, 2006 1:30 AM by Howard Lovatt

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 17 replies on 2 pages [ « | 1 2 ]
Tim LS

Posts: 37
Nickname: parchandri
Registered: Jul, 2005

Re: Static Behavioral Subtyping and Heron Traits Posted: Jan 8, 2006 7:27 AM
Reply to this message Reply
Advertisement
> 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), 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.

Problem 2) Let us call the overriding function the inner function, and the interface wrapper with its restrictions the outer function. Ideally the 'outer function' is only a check on the behaviour of the inner function. (Rationale: implementation isn't specified in interface.) So the inner function can imagine that when it returns a value, THAT is the value that gets returned. It should be impossible for the outer function to implement what value is returned.

Flow-on thoughts:
Q) What is a better way to restrict the return value? A return statement is much too confusing. Perhaps phrasing it as an assertion or postcondition.
Q) actually the writeln logging (looks kind of like aspect-oriented programming) creates side effects in terms of standard out, so isn't really a check on the behaviour either...

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Static Behavioral Subtyping and Heron Traits Posted: Jan 12, 2006 8:07 PM
Reply to this message Reply
> > 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.

Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: Static Behavioral Subtyping and Heron Traits Posted: Jan 13, 2006 1:30 AM
Reply to this message Reply
The objection that Tim Lovell-Smith has to the _override construct is the standard objection to the inner construct in Simula 67/Beta. The example I gave, of returning a value folling an _override call, was formulated they way it was for two reasons:

1. It is a good example for explaining what the construct does

2. It shows the interaction of inheriting Traits and classes implementing Traits

I am not suggesting that this is how the constrcct should be used, but it might be used this way. Note the Java equivelent:
abstract class Base {
  public final int one() { innerOne(); return 1; }
  protected abstract int innerOne();
} 
 
class Derived extends Base {
  protected int innerOne() { return 11; }
}
 
Derived d;
System.out.println( b.one() ); // prints 1
Base b = d;
System.out.println( b.one() ); // prints 1

Does not have this problem because it uses a final public method, a protected abstract inner method, and named subtyping.

Flat View: This topic has 17 replies on 2 pages [ « | 1  2 ]
Topic: Use cases for Generics Previous Topic   Next Topic Topic: Are Web Services an Investment or an infinite Cost?


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us