http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #23 from Stewart Gordon <[email protected]> 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: -------
