Talk:Design by contract/Archive 1

Archive 1

Time/Space Contracts

Somebody added something here on time/space contracts. If the person who edited that article this way sees this (or someone else who knows), could he/she tell me where information can be found on that? Thanks! Wouter Lievens 15:35, 28 May 2005 (UTC)

"Fail Hard"

Using the DBC methodology, the program code itself must never try to verify the contract conditions; the whole idea is that code should "fail hard", with the contract verification being the safety net. (This stands in stark contrast to the defensive programming methodology.) DBC's "fail hard" property makes debugging for-contract behavior much easier because the intended behaviour of each routine is clearly specified.

As a DBC newbie, I didn't understand much of this paragraph, and I don't know what "fail hard" means. A couple of minutes Googling didn't turn up anything relevant. Can someone define this term, and clarify this paragraph a bit? Axlrosen 19:15, 6 November 2005 (UTC)

It's not jargon; it mean just what it says: when a program fails, it should "fail hard" rather than trying to continue to run. As the article says, this concept is a bit controvercial. (I for one heartily endorse it during all phases of development except perhaps final deployment.) --Doradus 22:21, 6 November 2005 (UTC)

Verbosity

Yikes, this is an awfully verbose description of a fairly simple concept. Can it be tightened up so it reads more like an encyclopedia and less like a remedial software engineering text? --Doradus 21:24, 4 January 2007 (UTC)

Java Comparisons

Why is this being compared with Java (see: "compare to type bounds for Java 5 generics")? Isn't this a more or less language-neutral article? So why does it even need to be mentioned? It's not like Java 5 generics' type bounds are so common that everyone knows what they are. Just my opinion, could be I'm totally off the wall here. -- 156.34.80.248

Agreed; removing per WP:BB. -- intgr 10:32, 2 April 2007 (UTC)

Languages section

The "Languages implementing DBC" section currently pretty much only consists of a list of DBC implementations and links to their home pages; I think it takes up much more space than worth, and that Wikipedia articles should not contain inline external links unless they're sources. Would anyone oppose to turning it into a simple bulleted list of languages and stripping the external links? -- intgr 06:05, 5 April 2007 (UTC)

I can't found SpringContract in the spring documentation, while it's possible use AOP Infrastructure in Spring to implements contract, there isn't a specific sub-component for this purpose.

DBC contrasted to defensive programming?

The article currently says:

Using the DBC methodology, the program code itself must never try to verify the contract conditions; the whole idea is that code should "fail hard", with the contract verification being the safety net. (This stands in stark contrast to the defensive programming methodology.)

I believe this to be somewhat incorrect - while a "defensive programmer" may attempt to recover from contract (developer) errors, such as incorrect arguments, it needn't to, as far as I understand what defensive programming is about. In the case of DBC, runtime errors (e.g., network failures, hardware failures, privilege violations) still occur, and are part of the contract. Defensive programming still applies in the sense that these well-defined errors should always be handled. -- intgr 17:06, 24 November 2006 (UTC)

In defensive programming, the callee checks for errors. In DbC, the callee is allowed to assume that the caller has made no errors. I'm not sure what this has to do with network failures etc. --Doradus 17:38, 24 November 2006 (UTC)

Runtime errors like network failures, that would be part of the contract, are covered by "defensive programming". This means that the two approaches generally also work together – the client programmer will have to check for runtime errors defined by the contract. -- intgr 17:58, 24 November 2006 (UTC)

Network conditions can't appear in contracts. A program making assertions about entities outside its control is incorrect according to DBC. So I still don't see your point. --Doradus 17:56, 15 December 2006 (UTC)

Sorry, I am not following you. Do you mean that a program designed with design by contract, that does network operations, assumes that the network never fails? And if the network does fail, the program responds by "failing hard", e.g., segfaulting, as the contract was violated? I'm sure you agree with me that this would be ludicrous.

My view of network failures (for example) map to design by contract, is that the contract precisely defines how each object interacts in case of a network failure. Code using the network backend objects will check for these defined error conditions and act accordingly. This means that all anticipated error conditions are handled, and thus also qualifies as defensive programming.

Please explain what am I missing. -- intgr 18:10, 15 December 2006 (UTC)

Ah I think I see what you mean. I had it backward. Yes, contracts would describe the network failure modes. I guess in that sense a DBC program would be indistinguishable from one using defensive programming. The difference appears when a defensive program checks error conditions caused by other parts of the same software system. DBC doesn't do that. --Doradus 21:54, 15 December 2006 (UTC)

I use both defensive programming and DBC in the same projects. The "defensive" portion is usually the interface to a less reliable part of code -- especially, the public API of a library, or third party code (especially Microsoft authored code). I don't think defensive programming should be considered an alternative or contrasting with DBC in any way, as they work well together. The "defensive" areas of code have a less strict contract, but some contract is always present. —Preceding unsigned comment added by Frank Hileman (talk • contribs) 16:35, 7 March 2008 (UTC)

Who owns the trademark?

This article says that Eiffel Software owns the "Design By Contract" unregistered trademark. However, the web page at the Eiffel website says that "Interactive Software Engineering" owns the trademark.

I would like to site the proper owner of the unregistered trademark, but there is some discrepancy.

199.46.245.232 (talk) 01:46, 23 February 2008 (UTC)

The US Patent and Trademark Office lists "Design by Contract" as a Registered Trademark of "Interactive Software Engineering, Inc.".

199.46.245.232 (talk) 06:08, 23 February 2008 (UTC)

In this specific case, such a trademark is a good thing, since it stops others from using it. I think the concept has been defined earlier and better, then calling it "invariant conditions", and such a terminology is to be preferred, since it doesn't confuse compsci with business. ... said: Rursus (bork²) 20:01, 8 February 2009 (UTC)

Code example

The Spec_sharp wiki article had an easy-to-understand code example to explain the concept of DbC.

Could someone more knowledgeable add some code examples to the article? —Preceding unsigned comment added by Nothingist (talk • contribs) 00:40, 5 March 2010 (UTC)

Relationship with software testing

What is the purpose of the "Relationship with software testing" section. It doesn't even mention DbC at all, much less discuss its relationship with software testing. 76.170.161.30 (talk) 08:33, 21 March 2011 (UTC)

What term?

"History" starts with "the term was coined by...", but "the term" isn't defined. 99.195.207.112 (talk) 14:16, 25 June 2011 (UTC)

Requested move

The following discussion is an archived discussion of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

No consensus to move. Vegaswikian (talk) 08:10, 3 December 2011 (UTC)

Design by contract → Design by Contract – Fix capitalization. This is a trademarked proper noun, and Meyer (its inventor) and Eiffel Software (his company) consistently format it as such. The article's body text also has Contract capitalized. --Cybercobra (talk) 02:56, 26 November 2011 (UTC)

• Oppose – The article is about an approach that has a couple of names; the fact that one is trademarked is not very relevant. We should render the trademark in our normal styling, per MOS:TM and MOS:CAPS. It appears as "design by contract (DBC)" in more than one book (like this one) even while they acknowledge it as trademark. We can do the same, and should, per our style guidelines. Dicklyon (talk) 04:23, 26 November 2011 (UTC)
  • Funny you should cite MOS:TM: "Capitalize trademarks, as with proper names." --Cybercobra (talk) 06:43, 28 November 2011 (UTC)
• Comment – Even Meyer's own book treats it as generic, lower case. Dicklyon (talk) 14:48, 26 November 2011 (UTC)
  • Erroneous No, that's a result of the OCR process. See http://books.google.com/books?ei=0izTTumzBoPZiQKdnY3kCw&ct=book-thumbnail&id=xls_AQAAIAAJ&dq=%22typing%3B+design+by+contract%2C+assertions%2C+exceptions%22&q=design+by+contract#search_anchor (p576, actual scan image). --Cybercobra (talk) 06:42, 28 November 2011 (UTC)

• Oppose. The subject of this article is "an approach to designing computer software." Interactive Software Engineering claims trademarks (78/342,277, 78/342,308) for a specific computer program product that is not the subject of this article. The current situation, with a redirect Design by Contract, because the article discusses ISE's use, is appropriate. TJRC (talk) 20:34, 28 November 2011 (UTC)

The above discussion is preserved as an archive of the proposal. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

DbC abbreviation

Is the abbreviation DbC short for the general programming approach, or is it for Eiffel's trademark? If it is the latter, then it should probably be removed from the lead to this article. Dtm1234 (talk) 20:22, 28 June 2012 (UTC)

Eiffel Software's trademark is on the words "design by contract", as per the reference. "dbc" is not part of the registration. RossPatterson (talk) 22:10, 28 June 2012 (UTC)

Rename Article to use Generic Term

Since "design by contract" is a trademarked term, the WP article should be renamed to use one of the generic terms. While "invariant conditions" seems to be the historically accurate term, "code contracts" wins the current Googlefight. "Contract programming" has another popular meaning. "Programming by contract" is also ambiguous. The way WP handles Kleenex and Facial tissue is to explain that Kleenex is the trademarked term for facial tissue by the company that owns it and links to the generic term for the meat of the article. — Preceding unsigned comment added by BillMcGonigle (talk • contribs) 20:52, 8 December 2012 (UTC)

Oppose - "Kleenex" is a made-up word, whereas "design by contract" is an English phrase that describes the concept quite well. And as a counter-example, the article about rolling down hills in human-scale spheres was moved from the attempted-generic "Sphereing" to Zorbing, a made-up word that is trademarked in at least one country, and begins "Zorbing (globe-riding, sphereing, orbing) is the recreation or sport of rolling downhill in an orb, generally made of transparent plastic. RossPatterson (talk) 01:23, 10 December 2012 (UTC)

"Obliged" versus "obligated"

The words "obliged" and "obligated" have exactly the same meaning, so I'm inclined to agree with User:Rich_Farmbrough and use the simpler of the two. I disagree with User:SimonP's revert, and I'll re-revert unless anyone has an objection. --Doradus 13:46, 14 February 2006 (UTC)

There two words can actually have a different meaning. Consider these sentences:

He was obliged to her because of her actions

He was obligated to her because of her actions

Also obligated is North American English, while obliged is British, so this would fall under our rule of using the spelling of the original author. - SimonP 16:02, 14 February 2006 (UTC)

There is no clear cut distinction. OED agrees that legal requirement is included in "oblige" (as opposed to obligate), in its lengthy articles. More accessibly the American Heritage Dictionary says " To constrain by physical, legal, social, or moral means." Mirrim Webster has "to constrain by physical, moral, or legal force or by the exigencies of circumstance".

Furthermore Websters 1828 made the reverse distinction, saying of "Obligate" "Until recently, the sense of this word has been restricted to positive and personal acts; and when moral duty or law binds a person to do something, the word oblige has been used. But this distinction is not now observed."

Both words have been in use in the UK for some considerable time.

There are of course cicumstances where "obligate" is to be preferred, in direct quotes and in the technical senses of the word from finance and more importantly biology.

Rich Farmbrough. 16:24, 21 February 2006 (UTC)

Obliged and obligated don't have the same meaning. Read H L A Hart's "Concept of Law" for examples. If you're under duress to break the law, you're obliged to, not obligated to. 78.105.207.158 (talk) 13:01, 22 October 2013 (UTC)

Interfaces

Shouldn't there be some mention of interfaces in the article? There also would seem to be a need for some loose coupling with dependency injection (pun intended). — Preceding unsigned comment added by Amalgamate (talk • contribs) 14:32, 22 October 2014 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Design by contract. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20160328164727/http://cofoja.googlecode.com/files/cofoja-20110112.pdf to https://cofoja.googlecode.com/files/cofoja-20110112.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 00:27, 3 December 2017 (UTC)

"Languages with third-party support" cleanup plan

The list is indiscriminate and has lots of external links, when the Wikipedia policy is no external links in the main article section.

There was a similar issue with List of build automation software, where people kept adding random build tools to the list. I "solved" it by putting those on the Software wiki, an external wiki I found that doesn't have a strict policy on external links like Wikipedia. Looking at the history it seems most people aren't aware of the Software wiki page and haven't stopped adding tools to the Wikipedia page, but at least the Software wiki page got updated a few times.

So my plan is to do a similar "solution", move the whole list to the Software wiki and keep some of the libraries that have their own wiki pages. Sound good? --Mathnerd314159 (talk) 18:40, 12 January 2022 (UTC)

Security concerns

The world of IT has evolved at lot since Meyer´s initial publication in 1986, and key assumptions do no longer hold. The idea that a client will always produce correct data is naïve and irresponsible, and in direct conflict with IT security best practice (e.g. https://owasp.org/Top10/A03_2021-Injection/, https://owasp.org/www-project-proactive-controls/v3/en/c5-validate-inputs). We should look at DbC as an interesting historic side-note, but no longer an "approach for designing software". Raffen (talk) 12:53, 21 April 2022 (UTC)