[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 #23 from Stewart Gordon <smjg at iname.com> 2012-05-03 18:21:44 PDT ---
(In reply to comment #22)
>> If you mean whether a given call is legal, then you could by the 
>> same argument insist that called method names must be resolved in 
>> the context of the virtual type.
> 
> And they are.  It's what the vtbl[] is for.

???

class A {}

class B : A {
    void foo() {}
}

void main() {
    A a = new B;
    a.foo();
}

You're claiming that this code is legal, and the penultimate line resolves to
B's foo method???

>> (b) is going to continue to be exempt from this requirement.
> 
> 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.

The concept of overriding in OOP as I've been brought up to understand it
applies to what the method does, a quite different concept from what are legal
inputs to it.

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

I'm surprised that the classic OOP spec covers the behaviour of contracts at
all.  But maybe I just need to read up on it.

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

At least I seem to have three potential co-authors already....

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