[Issue 6856] Absence of in() contract (precondition) should mean use default precondition instead of ignore inherited in() contracts

2013-01-22 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6856


Leandro Lucarella leandro.lucare...@sociomantic.com changed:

   What|Removed |Added

   Severity|enhancement |normal


--- Comment #31 from Leandro Lucarella leandro.lucare...@sociomantic.com 
2013-01-22 07:24:33 PST ---
(In reply to comment #28)
 Not sure why this wasn't flagged as INVALID before.  But now that the summary
 line's changed and some comments to the effect of it have been posted, it's
 essentially an enhancement request.  But it'll probably be rejected because 
 the
 code breakage that would result.

The line between a fix and an enhancement here is very thin. As other people
pointed out, in contract inheritance as they are are not only useless, but
extremely dangerous, because they give a false sense of security. Is really
hard to debug a problem where you think some preconditions are met (because the
code say so), but they really aren't.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 6856] Absence of in() contract (precondition) should mean use default precondition instead of ignore inherited in() contracts

2013-01-21 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6856


Stewart Gordon s...@iname.com changed:

   What|Removed |Added

   Severity|normal  |enhancement


--- Comment #28 from Stewart Gordon s...@iname.com 2013-01-21 16:42:41 PST ---
Not sure why this wasn't flagged as INVALID before.  But now that the summary
line's changed and some comments to the effect of it have been posted, it's
essentially an enhancement request.  But it'll probably be rejected because the
code breakage that would result.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 6856] Absence of in() contract (precondition) should mean use default precondition instead of ignore inherited in() contracts

2013-01-21 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6856


bearophile_h...@eml.cc changed:

   What|Removed |Added

 CC||bearophile_h...@eml.cc


--- Comment #29 from bearophile_h...@eml.cc 2013-01-21 17:12:25 PST ---
(In reply to comment #28)

 But it'll probably be rejected because the code breakage that would result.

In several cases breaking some code is the best solution. Is this one of those
cases?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 6856] Absence of in() contract (precondition) should mean use default precondition instead of ignore inherited in() contracts

2013-01-21 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=6856



--- Comment #30 from timon.g...@gmx.ch 2013-01-21 21:45:01 PST ---
(In reply to comment #28)
 Not sure why this wasn't flagged as INVALID before.  But now that the summary
 line's changed and some comments to the effect of it have been posted, it's
 essentially an enhancement request.

This issue makes the feature basically useless. About half the point of
contracts is that they are inherited. The spec contains a bug. This is not a
valid implementation of dbc.

 But it'll probably be rejected because the code breakage that would result.

Code is broken now, without contracts catching it because people do not care
about tracking down all methods that override a method that specifies an
in-contract and adding an in { assert(0); } contract.

It is basically never the case that a overridden method does not need to rely
on any in-contract if the super class method does. This is stupid, and everyone
actually using the feature will agree with me.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---