Nice TWiki > Doc > NiceTutorial > SuperCall TWiki webs:
Dev | Doc | Main | TWiki | Sandbox
Doc . { Changes | Index | Search | Go }
This page documents the current super mechanism in Nice. It compares it with super in Java, and calls for discussion on ehancements. First, it does not make sense to just copy Java's semantics. In Java you write:
class B extends A
  void m(int x) { super.m(x); ... }

So super in Java means roughly "fetch the following method in my superclass". With multi-methods this does not make sense, since methods consider all arguments to choose the implementation, not just the first one.

Another odity with Java is that you call call a different method than the current one, or pass it other arguments than the arguments of the current method. I think at least that calling the same method with the same arguments is by far the most common, so it should be more natural to do it, without having to reapeat the method name and arguments.

So the current definition in Nice is that super is an expression that calls the next implementation of the current method, with the same arguments. So the example would become:

class B extends A
  m(x) { super; ... }

I would be interested to hear if other cases are useful in practice (calling a different method, or passing different arguments). These pose more theoretical problems. For instance the Dylan language says that passing different arguments is fine as long as they will result in the same implementation to be chosen, otherwise the result is undefined.

-- DanielBonniot - 12 Jul 2002

Passing different arguments would allow something akin to "around advice".

Some mechanism for controlling which parameters are "relaxed" when looking for the super method would also be good, though I can't think of a syntax. For example, I'd like some thing of this sort to work...

class M {}
class N extends M {}
class O extends M {}

class A {
  int f(M m) = 4;
  f(m@N) = 5;
class B extends A {}
f(me#B, m)   { log(m); return super; }
f(me#B, m@N) { log(m); return super; }  // required to disambiguate f(me@B,m@N)
However the disambiguation line causes the super call to itself be ambiguous, f(@_, m@N) vs f(me#B, @_). The end result is removal of f(me#B, m) and replication of f(me#B, m@N) for every subclass of M.

-- RohanHart - 14 Oct 2003

Do you need a duplicated method to get the behaviour you want? Rewriting it to the following solves the ambiguaty too.

class A {}
class B extends A {}

int f(A me, M m) = 4;
f(me#A, m@N) = 5;  //used #A here instead of the implicit @A when the method is in the class

f(me#B, m)   { return super; }

That's not much better in my case as the "A" class is really abstract and hence can't be exact matched, leading to duplication over the concrete subclasses instead. Plus I've found a special case for one of the parameters at the me#B level, requiring duplicates of the general case otherwise it becomes a candidate for the super call in the special case. -- RohanHart - 15 Oct 2003

I think it's useful to have more control over which parameter are the more important ones especially in super calls.

A possible solution is to split up super in super(as in java) and resend(as currently in Nice). This is done in MultiJava?. Quote:

"A super send always invokes a method in some superclass of the enclosing class. More specifically, a super send will invoke the most-specific method for the given actual arguments that appears in some (possibly transitive) superclass of the enclosing class. On the other hand, resend simply invokes the most-specific overridden method of the enclosing method, even if that overridden method exists in the same class."

-- ArjanB - 14 Oct 2003

Topic SuperCall . { Edit | Attach | Ref-By | Printable | Diffs | r1.6 | > | r1.5 | > | r1.4 | More }
Revision r1.6 - 14 Oct 2003 - 23:42 GMT - RohanHart
Parents: WebHome > NiceTutorial
Copyright © 1999-2003 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback.