[Issue 302] in/out contract inheritance yet to be implemented (page 2)

http://d.puremagic.com/issues/show_bug.cgi?id=302 ------- Comment #6 from llucax@gmail.com 2009-04-22 08:35 ------- (In reply to comment #5) > (In reply to comment #4) > > The spec specifies what the code should do, but the code being generated does > > something else. How is that not the very definition of wrong-code? > > (This probably falls in the "the front-end is sending incorrect data to > > the backend" category) > > > > Never having been implemented doesn't change any of this, IMHO. > > I think the problem is in the spec in this case. When it's not implemented, it should either marked as not yet implemented in DMD, or it shouldn't be in the spec at all yet. _Every_ other case of wrong-code in bugzilla is different. The nature of the issue is completely different, so I really think it's unhelpful to use the same keyword for both. I don't think is a good idea to change the specs according to DMD. DMD is just an implementation, an incomplete one. It's not serious to change an spec because an implementation don't implement a feature! I don't know if this is wrong-code or not, but I know it's not a spec issue, is a missing feature in DMD. So please, please, please, don't change the specs, fix the implementation. Thanks! --

http://d.puremagic.com/issues/show_bug.cgi?id=302 ------- Comment #7 from smjg@iname.com 2009-04-22 09:53 ------- (In reply to comment #6) > So please, please, please, don't change the specs, fix the implementation. I entirely agree. Moreover, I proposed a strategy more than 3 years ago. So why is it taking so long? --

http://d.puremagic.com/issues/show_bug.cgi?id=302 ------- Comment #8 from maxmo@pochta.ru 2009-04-24 05:38 ------- Isn't it trivial to implement? --- Foo bar(A a, B b, C c) { try{super.inConstract(a,b,c);} catch(Throwable){this.inConstract(a,b,c);} //body super.outContract(result); this.outContract(result); return result; } --- --

http://d.puremagic.com/issues/show_bug.cgi?id=302 ------- Comment #9 from clugdbug@yahoo.com.au 2009-04-24 07:19 ------- Here's the link to Stewart's original post. http://www.digitalmars.com/d/archives/digitalmars/D/31595.html Note that Walter seems to have rejected Stewart's 3rd point, 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 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. --

http://d.puremagic.com/issues/show_bug.cgi?id=302 ------- Comment #10 from maxmo@pochta.ru 2009-04-24 08:14 ------- He rejected to call in contract by caller, because it obviously should be called by callee. ps yeah, checking this contract before super contract is better :) --

April 24, 2009

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

Posted by d-bugmail
in reply to d-bugmail

Permalink

d-bugmail

Posted in reply to d-bugmail

Permalink

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


smjg@iname.com changed:

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




------- Comment #11 from smjg@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.


--

http://d.puremagic.com/issues/show_bug.cgi?id=302 ------- Comment #13 from smjg@iname.com 2009-05-04 08:48 ------- But if the arguments to a method aren't guaranteed to pass the base class contracts, one wouldn't be calling it through a base class reference. Hence my point. --

http://d.puremagic.com/issues/show_bug.cgi?id=302 Walter Bright <bugzilla@digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |bugzilla@digitalmars.com Resolution| |FIXED --- Comment #14 from Walter Bright <bugzilla@digitalmars.com> 2009-10-06 02:10:59 PDT --- Fixed dmd 1.048 and 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

Forums