How to use mixins effectively

[Tom Wieland]

Hi all.

I'm struggling with understanding how to correctly set up a directory structure with classes and mixins, or rather what is correct.

The project I'm reordering and rewriting in LiveScript is id-project, a small tree of (now CoffeeScript) classes that allows me to easily set up servers with little configuration and automatic Seaport connectivity.

The current situation is:

What I would like to do is to take all the Seaport functionality out of Server and place it in Seaport, which would then be a mixin and not a class, so any implementation of the Server and it's children could choose to have Seaport management or not (in which case the port would be set from the constructor of Server):

1. Is this design correct/okay? Server#start and Server#stop actually do exactly nothing but emit "start" and "stop" and return this, so should I totally remove these?
   
2. The functionality of the Seaport mixin includes setting the port property on the Server instances, but doesn't have this property itself, so it is very side-effectful. What if a class tries to implement it that has no port property? Because you just can in js.. it would just get added. Does that mean I should just include all class properties that a mixin will change in the mixin or does it mean I should only provide classes that have the correct properties for implemetation of a mixin?
3. What I don't understand about mixins is if they are intended for only one class (tree) or if they should work on all classes.
   
4. I'm not sure how to bundle mixins with the classes. How to structure your CommonJS modules. Given:
   id-server/
     http/
       HTTPServer.ls
       ExpressServer.ls
       KeystoneServer.ls
     tcp/
       TCPServer.ls
       RPCServer.ls
       LevelDBServer.ls
     Server.ls
   Should I put mixins at:
   id-server/
     mixins/
       Server/
         Seaport.ls ?
       Seaport.ls ?
     Server/
       mixins/
         Seaport ?
       Seaport.ls ?
   

[George Zahariev]

Looks good.

Basically how mixins work is they just copy over all the properties from the mixin to the class prototype. You should only really have functions defined in the mixin. You can use a mixin on anything, it's just copying over its contents to different classes. Thankfully, this copying is OK as JavaScripts dynamically scoped this works out like we want (for once).