Changed InvocationReceiver into an interface because it needn't be a class

and that allows classes that normally do other things to register
themselves as an invocation receiver.


git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@179 542714f4-19e9-0310-aa3c-eee0fc999fb1

src/java/com/threerings/presents/client/InvocationReceiver.java

@@ -1,34 +1,36 @@
 //
-// $Id: InvocationReceiver.java,v 1.1 2001/07/19 19:18:06 mdb Exp $
+// $Id: InvocationReceiver.java,v 1.2 2001/08/04 02:31:20 mdb Exp $
 
 package com.threerings.cocktail.cher.client;
 
 /**
- * Classes registered to process invocation notifications should extend
- * the invocation receiver class and register themselves with the
+ * Classes registered to process invocation notifications should implement
+ * the invocation receiver interface and register themselves with the
  * invocation manager. Because the invocation notification procedures are
- * looked up using reflection, there are no methods to override in the
- * receiver class, but it serves as a useful point for documentation and
- * as a useful indicator that the derived class in question is actually
- * serving as an invocation receiver.
+ * looked up using reflection, there are no methods to implement in the
+ * receiver interface, but it serves as a useful point for documentation
+ * and as a useful indicator that the class in question is serving as an
+ * invocation receiver.
  *
  * <p> Invocation notifications are identified by a module name and a
  * procedure name. The module name identifies which invocation receiver
  * instance will receive the notification. Receivers are registered with
  * the invocation manager as handling all notification procedures for a
  * particular module. The notification procedure name is used to construct
- * a method name which is then reflected and invoked. The name
- * construction is as follows: a notification message requesting the
- * invocation of a procedure named <code>Tell</code> will result in a
- * method named <code>handleTellNotification</code> being invoked on the
- * invocation receiver instance. The signature of that method is defined
- * by the arguments supplied with the invocation notification message.
- * These arguments must always be of the same type and must exactly match
- * the signature of the implementing method (with the standard reflection
- * argument type conversion process taken into account).
+ * a method name which is then reflected and invoked.
+ *
+ * <p> The name construction is as follows: a notification message
+ * requesting the invocation of a procedure named <code>Tell</code> will
+ * result in a method named <code>handleTellNotification</code> being
+ * invoked on the invocation receiver instance. The signature of that
+ * method is defined by the arguments supplied with the invocation
+ * notification message.  These arguments must always be of the same type
+ * and must exactly match the signature of the implementing method (with
+ * the standard reflection argument type conversion process taken into
+ * account).
  *
  * @see InvocationManager#registerReceiver
  */
-public class InvocationReceiver
+public interface InvocationReceiver
 {
 }

tests/src/java/com/threerings/presents/client/TestReceiver.java

@@ -1,12 +1,12 @@
 //
-// $Id: TestReceiver.java,v 1.1 2001/07/19 19:18:06 mdb Exp $
+// $Id: TestReceiver.java,v 1.2 2001/08/04 02:31:20 mdb Exp $
 
 package com.threerings.cocktail.cher.client.test;
 
 import com.threerings.cocktail.cher.Log;
 import com.threerings.cocktail.cher.client.InvocationReceiver;
 
-public class TestReceiver extends InvocationReceiver
+public class TestReceiver implements InvocationReceiver
 {
     public void handleTestNotification (int one, String two)
     {