On Thu, Dec 20, 2012 at 08:26:18AM +0100, Jacob Carlborg wrote:
> On 2012-12-20 01:06, 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/
[...]
> >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
> >
>
> What's the difference compared to calling "super".
[...]
The difference is that you can do things like this:
class Base {
abstract void chainMe() {
if (condition) {
chainMe(); // recursion
} else {
inner.chainMe();
}
}
}
Which cannot be easily reproduced using .super.
T
--
Ruby is essentially Perl minus Wall.
