[Issue 6857] Precondition contract checks should be statically bound.

[d-bugmail at puremagic.com]

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



--- Comment #26 from deadalnix <deadalnix at gmail.com> 2012-05-04 01:46:25 PDT ---
(In reply to comment #22)
> You cannot widen the requirements of a function without providing an override
> of it. A.foo() cannot be called with the widened requirements of B.foo() -
> B.foo() gets called. That's why it can be overridden. IT WORKS CORRECTLY. The
> virtualness of the contracts is directly connected to the virtualness of the
> function calls.
> 
> As for the design decision on this, the decision was (and is) to implement
> classic OOP. It is theoretically sound. This is well trod and (I thought) well
> understood territory. As Andrei pointed out, it is not open for debate what OOP
> is.

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.

> 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 ? If it does, I'd
be interested in what is the reasoning. The fact is that all document I read at
this point do not say anything about this.

> If we try and implement alternate and incorrection notions of OOP, D will be
> considered a lightweight language run by amateurs.
> 

I do agree, but once again, OOP isn't about contracts.

> It is entirely possible that:
> 
> 1. I have seriously misunderstood OOP (I have made more than my share of such
> mistakes before).
> 
> 2. The OOP community has got it all wrong.
> 

You perfectly know that both are unlikely. Stating this avoid any interesting
debate. As for now, we have 25 comment, and not once mention any argument in
favor of keeping the standard behavior instead of the proposed one.

> 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).

I'd be happy to see ONE argument on favor of the current behavior. Everybody is
doing it isn't a valid argument. 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.

PS: Note that in case of Spec#, the decision is made to DISALLOW override of in
contracts. In such a situation, both behavior proposed in this thread are
equivalent, and so, it is not a relevant example.

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