So, I’ve started over with NeatTools. There has been some recent interest in rebooting the real NeatTools, which got me more interested in the AS3 versions again. Last time, I got bogged down with figuring out how to manage the connections, so I’m rebuilding it from scratch, and hopefully I can figure out the best way to handle these pesky connections between modules. I have a lot of questions about how to handle them though.
- Should connections be independent objects with references to the modules they connect?
- Should modules contain the connection object instead?
- Should connections just be imaginary and instead should modules contain a reference to any module they are connected to?
- Should there be duplicate references (ie, should moduleA know it’s connected to moduleB and vice versa)?
- Should modules only know what they’re outputting to, but not care what might be plugged into the back of them?
Anyway, here’s the current version. You can drag out a line from the outputs, but the connection function doesn’t do really anything at the moment, it just draws a strange line (so I can see something happened).
This movie requires Flash Player 9
Working backwards…
I think it would overly-complicate things to have modules “know” what they are connected to. Surely inputs have to be evaluated for type, and outputs can only be connected to inputs; otherwise, connectivity should be rather blind. The arrival of new data on one or more inputs stimulates the module to possibly (but not necessarily) generate one or more new outputs.
It’s hard to imagine a complete data sink, where no downstream data emerges, but certainly modules that filter incoming data might emit new values less frequently than new data is received. Also, a module controlling a computer peripheral or device might not generate outputs, except perhaps an error.
To my mind, it boils down to 4 kinds of objects–diagrams, modules, connections, and nodes. Each object has its own list of properties. Diagrams consists of collections of the other three objects, but may become a module in another diagram. Modules are functional units that have nodes. Nodes can be connected to one or more other nodes. Inputs can have only one source, while outputs can have multiple sinks.
Modules can now be almost any code object as long as they conform to certain rules, and the diagram becomes divorced from processor, OS, etc. I think this also allows dynamic operation during development that can also be compiled into a stand-alone executable.
I am, of course, glossing over all the hard parts.
I’ve discovered it IS very complicated, to have modules know what they are connected to. For instance, a path I went down, outputs and inputs are both objects contained by the module. So as an example, the output detects that I’ve clicked it and starts me dragging line, and if I release it over nothing, the output needs to kill the line and do nothing, however, if I release it over the input of another module, something needs to create a connection betwixt these two, but which one? should the input detect an MOUSE_UP event? how will IT know that something is trying to connect to it, rather than just me clicking on it? It got to be a bit of a mess, so I’m creating a workspace object that will hold all the modules, and connections (diagrams); more of an outside in approach, rather than inside out.