Contract Programming :-)
int chain(...)
{
preConstracts()
inner.chain() // calls derived chain function
postConstracts()
return ...
}
Scly
On Thursday, 20 December 2012 at 00:07:49 UTC, H. S. Teoh wrote:
On Thu, Dec 20, 2012 at 12:11:34AM +0100, Andrej Mitrovic wrote:
Some interesting blog post:
http://journal.stuffwithstuff.com/2012/12/19/the-impoliteness-of-overriding-methods/
It's a post about a common problem in class design, I've ran
into it a
few times in D too.
[...]
Interesting concept. So "polite" overriding is simply a kind of
override
where the derived class method has a vtable entry separate from
the base
class method's entry (and thus needs explicit invocation from
the base
class), whereas the usual "impolite" overriding is a kind of
override
where the derived class method replaces the vtable entry of the
base
class method.
I can see use cases for both kinds of overriding.
Interestingly enough, in the "polite" overriding case, the call
to inner
is undefined until it's defined in the derived class. Which
means that a
method that calls inner is a kind of pseudo-abstract method
(since
abstract methods are those that *must* be implemented by the
derived
class). So if we were to implement this in D, we could extend
the
meaning of 'abstract':
class Base {
// The current, usual overridable method
void replaceMe() {
writeln("A");
}
// Abstract, because chain(chainMe) is undefined until
// the derived class implements it.
abstract void chainMe() {
writeln("B");
inner.chainMe(); // call derived class method
// 'inner' is a tentative
// keyword
writeln("C");
}
}
class Derived : Base {
override replaceMe() {
writeln("D");
Base.replaceMe();
writeln("E");
}
// Base.chainMe is abstract, so we have to implement
// this method.
override void chainMe() {
writeln("F");
}
}
void main() {
auto d = new Derived();
d.replaceMe(); // prints D A E
d.chainMe(); // prints B F C
}
T
