general thoughts on modularization and code refactoring

[edmundchong]

Hi @glopesdev continuing our prematurely-ended, elevator conversation here. Bonsai works well for me for many things, just wanted to say basically my experience, having heavily used bonsai for many variants of experiments, is that I've found trouble with the following:

1. Modularization--I do use many SavedWorkflows to write re-usable functions. But in general I've found that defining functions this way is slightly more clunky / maybe potentially less clean / readable than in other programming languages say python where its straightforward to specify what sets of inputs it takes, and what outputs it spits out, defining what variables are local to the function and die upon completion. I am able to do all that in a GroupWorkflow which I save, but it gets clunky / unreadable with increasing complexity. Or perhaps there already is some standard way that you do it that I need to learn, or just turn more to CSharpExtensions?

2. Code refactorization / code search. Is it correct that the search function currently only works for SubscribeSubjects? So for example, I cannot easily where I have initialized a Subject or where I am multicasting to that Subject etc. I have found it not straightforward to track down all places in a workflow which are related to a given Subject. Also, if I want to rename a Subject, is there a quick way to do so beyond going to each one manually?

Possibly both issues are already resolved but I lack the proper knowledge :)

[glopesdev]

I've found that defining functions this way is slightly more clunky / maybe potentially less clean / readable than in other programming languages say python where its straightforward to specify what sets of inputs it takes,

I am going to assume that by "inputs" here you mean WorkflowInput nodes.

About WorkflowInput nodes there are usually three things one would like to know to understand how to call a group node:

1. how many there are (i.e. how many possible inputs can you send to the group)
2. what types are acceptable to send to each input
3. the order of the inputs

The editor provides reasonable support for 1. but the error messages may be confusing because of #1059.

As for 2. it is actually possible to force/specify the type of the input to the group. Take any workflow node providing the input type you are interested in and from the right-click context menu select "Create Source > WorkflowInput". This will create a WorkflowInput node specifically of that type. This will make it so that sending incompatible types to the node will throw an error (if convertible types or subtypes are provided, it will still work).

As for 3. the order of inputs is determined by the label indicated in the WorkflowInput node itself (Source1 is the first, Source2 the second, etc) and they will be matched to the outer inputs following the usual top-to-bottom ordering, so hopefully not too confusing.

and what outputs it spits out,

Regarding what outputs a node sends, there is always only exactly one output sequence, and its type is determined strictly by the set of operations specified in the workflow itself. Here I don't think we are so different from languages like Python where functions can actually return anything they want at runtime.

At least in the case of Bonsai we know immediately and ahead of time what the output type is because type-inference is performed on the workflow (simply right-click any node).

But maybe what you mean here is a question of group workflow documentation, which is another topic which may be worth discussing how to make easier.

defining what variables are local to the function and die upon completion.

Here I am assuming that by "variables" you mean Subject nodes.

About Subjects the scoping rules are well-defined in the docs. You can use Defer or other closed-scope nodes internally in the group workflow to make sure any internal variables are local only to your function.

Is it correct that the search function currently only works for SubscribeSubjects? So for example, I cannot easily where I have initialized a Subject or where I am multicasting to that Subject etc.

It is true the search function currently does not differentiate between subscribe and multicast nodes (this could change soon).

However, in terms of finding the original declaration the editor does support it. Simply right-click any subject in the toolbox or in the workflow and from the right-click context menu select "Go to definition" (or press F12).

Also, if I want to rename a Subject, is there a quick way to do so beyond going to each one manually?

Yes, simply click on any subject (subscribe / multicast / declaration) and press F2 or right-click the subject and choose "Rename". This will rename all uses of that subject and correctly take into account the aforementioned scoping rules. However, bear in mind that subjects used inside include workflows will not be renamed since the include is read-only. There were some early discussions about whether to support this if the include workflow explicitly externalized a property with the subject name, but this has not been implemented yet.

Thanks for the feedback, these are all important questions we are considering in our path towards making it easier to deal with larger workflows.