--- Comment #27 from Andrei Alexandrescu <> 2012-05-04 
04:03:36 PDT ---
(In reply to comment #26)
> No it isn't. OOP doesn't say anything about contracts. The concept of contract
> is different and the question here is how both interact in a specific corner
> case.

Walter's explanation creates confusion because he uses the wrong vocabulary
(i.e. OOP instead of Design by Contract). 

> > I realize I am not very good at explaining this. I seriously recommend 
> > reading
> > Meyer's book Object Oriented Programming. It's only $5.99.
> Is that book handle the corner case we are talking about here ?

Yes. There's another book on the subject called "Design by Contract, by
Example". I wouldn't recommend it as a good book in general but it does teach
the topic.

> If it does, I'd
> be interested in what is the reasoning.

Well it's not all that reasonable to expect someone to essentially copy the
text from the book or summarize it for you. 

> The fact is that all document I read at
> this point do not say anything about this.

It means you are reading the wrong documents. It takes literally under a minute
to find relevant documents all over.

> > As evidence for (1), is there any OOP language that does it these other 
> > ways?
> > Spec# does not, as Andrei researched and pointed out. For (2), you've got a
> > high bar to overcome, and certainly have an opportunity for a groundbreaking
> > academic paper.
> I read many paper on the subject. None was covering the corner case we are
> talking about here. Without this corner case, both solutions satisfy
> requirements. However, the chosen one is simpler (in contract can simply be
> added to the function body).

There's no reason to doubt you are telling the truth, so this must be quite an
interesting case of confirmation bias as you seem to have read only what
doesn't infirm your hypothesis and glossed over everything that does.

As an example, google for

"design by contract" inheritance

The literally FIRST hit takes to a slide deck, see There
there is theory and examples on how contracts work. 

> I'd be happy to see ONE argument on favor of the current behavior. Everybody 
> is
> doing it isn't a valid argument.

It's a very valid argument. DbC is established. People learn about DbC from
various places and they come to apply it in D. They'd be surprised and annoyed
that D doesn't do what it's supposed to do. There are of course other
arguments, which you can find in the literature. This is not the time and place
for a course in DbC.

> We are D, we know everybody is using C++ and
> PHP (among others), and we do also know that such languages are horribly
> crippled by all sort of crazyness. Everybody is doing it isn't an argument.

On the other hand many are also doing some good things so gratuitously not
doing them doesn't help, either.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to