plugin architecture refactor to instance attributes

[jdhenke]

// @willzeng, i'd be interested in your thoughts on this

i've thought of a different way to share instances of each plugin with each other. it essentially requires classes to articulate the instance dependencies it has and assigns each instance of a plugin attributes which are the instances of the other plugins.

Example Interface

class Plugin

  # string unique to all other plugins
  @uri: "Plugin"

  # dictionary mapping attribute name to URI of other plugin
  @needs:
    "plugin2": "Plugin2"

  # now attributes are available, even in the constructor
  constructor: () ->
    expect(@plugin2).toBeDefined()

So each plugin class specifies

• a uri, which uniquely identifies the plugin
• a needs attribute, which is a dictionary with key, value pairs st. the instance of the plugin with the uri equal to the value is assigned as the attribute named by the key.

  Reason I Like This

• dictionaries are more concise than functions
• you typically are storing certain instances as attributes anyway
• because the class definitions specify their dependencies, it codifies the partial ordering of dependencies. celestrium can leverage this to check for cycles, providing helpful errors if they exist. it also then can ensure plugins are initialized in the correct order, removing the need for the developer to know the dependencies and list them in order.

[jdhenke]

If you're curious about implementation, here's how, given a class definition, it can be extended with certain attributes to make them available in the constructor without modifying the original definition.

class Person
  @uri: "Person"
  constructor: () ->
    console.log @name

class Dude extends Person

Dude::name = "joe"

new Person()
new Dude()

This prints

undefined
joe

[willzeng]

This would certainly be good as Plugins become numerous and interdependent (we should be able to produce a nice GraphView of the plugin dependencies...)

Do you know how to implement expect(@plugin2).toBeDefined() ?

[jdhenke]

That's just a jasmine syntax for saying, @plugin2 will be defined in the constructor.

[jdhenke]

// @willzeng

(we should be able to produce a nice GraphView of the plugin dependencies...)

I generated this programmatically leveraging my new infrastructure. So meta...