[Issue 302] in/out contract inheritance yet to be implemented

d-bugmail at puremagic.com d-bugmail at puremagic.com
Fri Apr 24 08:35:35 PDT 2009


http://d.puremagic.com/issues/show_bug.cgi?id=302


smjg at iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg at iname.com




------- Comment #11 from smjg at iname.com  2009-04-24 10:35 -------
(In reply to comment #8)
> Isn't it trivial to implement?

It is, but not by your code because....

> ---
> Foo bar(A a, B b, C c)
> {
>   try{super.inConstract(a,b,c);}
>   catch(Throwable){this.inConstract(a,b,c);}

There could be any number of classes in the hierarchy between Object and the
type of this.  This would check only the contracts assigned to this.bar and
super.bar, nothing higher up.  Same applies to your out checking code.

(In reply to comment #9)
> Note that Walter seems to have rejected Stewart's 3rd point,

He didn't.  He merely gave a counter-argument to /one tiny detail/ of point 3. 
Moreover, tweaking what I wrote to put in contract checking on the callee side
is trivial.

> which is part of the reason I don't think this is a spec bug rather 
> than wrong-code... it's not clear to me that we know what the 
> correct code is.

The only spec issues in my post are 4 and possibly 2.  But 2, while nice,
doesn't need to be done just to get this working at a basic level.

> The task should be separated into dependent bugs. Stewart's first 
> point should become a new Phobos bug -- it's something Sean can fix 
> if it still applies.

I don't get you here....

(In reply to comment #10)
> He rejected to call in contract by caller, because it obviously should be
> called by callee.

Why obviously?

Advantages of in contract checked by caller:
- A library can be compiled in release mode, and programs using the library can
still have the checks that they're using it correctly.
- If a method is called through a base class reference on a derived class
object, it is sufficient to check the base class contract, possibly saving
computational cost.
- Combined with allowing contracts without body, it could enable contracts to
work on closed-source libraries, without forcing the creator to distribute two
versions of the .lib.

Advantages of in contract checked by callee:
- Slightly less code in development builds.
- ....

But at least getting something working is more important than coming to a final
decision on this little detail.  Currently, the spec leaves where to do the
contract checking up to the implementation.


-- 



More information about the Digitalmars-d-bugs mailing list