Example using a command-like pattern

[GoogleCodeExporter]

Is there any example of how to setup a struct (or interface) that has a method 
that can be overriden (say func Process interface{})?

The project sounds pretty cool, but since it doesn't accept interfaces (I 
removed the check for *struct when validating the channels, but now it fails 
silently somewhere), it's pretty hard to code for it.  The problem is that I 
would have to create a channel for each type of command the clients would 
understand, or create my own marshaller...

Any examples of doing this? 

Original issue reported on code.google.com by ghex...@gmail.com on 14 Jun 2010 at 2:40

[GoogleCodeExporter]

Hello,

I am not sure if a channel of interface type can be "remoted". The problem is 
at receiving router, internally we need create a new "empty" object to 
deserialize to. Interface only defines the method-set. If we attach a channel 
of interface type to an id in router, the receiving router doesnt know how to 
create the "empty" object. 

We may have two ways around this:
1. in future, Go may have "variant" type 
(http://golang.org/doc/devel/roadmap.html) which will help.
2. although we cannot have remote "polymorphic" channels, we can rely on 
interface for polymorphism. An thought could be as following:

   //define a "generic" CmdMsg which could serialize data of all commands types
   type CmdMsg struct {
        Kind int  //tags for diff command types
        Data string
   }

   //define the command interface which can serialize to the generic CmdMsg
   type Cmd struct {
        Process(data interface{})
        Serialize() (*CmdMsg, os.Error)        
        Deserialize(msg *CmdMsg) os.Error
   }

each concrete command types can define their own code for 
Serialize/Deserialize. all commands will use 

Maybe this could help?

Regards
Yigong

Original comment by yigongli...@gmail.com on 16 Jun 2010 at 6:00

[GoogleCodeExporter]

Yes, that is along the lines of what I've been playing with (I used a string 
for the type, but an int is more efficient).  It's a pity the serialization and 
reflection layer in Go is so limited (there's no real reason for it, it could 
be more Java-like).

Thanks for the suggestion.

Original comment by ghex...@gmail.com on 16 Jun 2010 at 5:44