[For discussion] ideas to augment gen_to_unit and/or Gen base class.

[cboulay]

Hi @pperanich , I've been using the generator pattern quite a bit. Most of the Units that I have in my project's pipeline are now using a generator method under the hood which has allowed me to write more comprehensive unit tests on the core functionality, improving that functionality in the process.

I have a few ideas or topics for discussion on integrating a generator method into a Unit.

1. Add a suffix to the stream name depending on the message type.

A simple patch implementing this is in pr #74 However, this only adds _SIGNAL for AxisArray message type because AFAIK that's the only one available in the core. Maybe this can use strings instead of types to allow it to use other message types? The next-lowest-hanging fruit would be the _TRIGGER suffix.

2. If the message type is Union[MsgType1, MsgType2], create unique streams for each MsgType.

This can be controlled by a flag passed by gen_to_unit. e.g. gen_to_unit(generator, split_union=False).
With this suggestion, I'm still struggling with a good syntax to map which streams are combined into a single sub/pub method and which are standalone publishers or subscribers. Maybe another argument to gen_to_unit providing the map?

3. In gen_to_unit, if the generator's (split) return type is List[MsgType], iterate over the generator's return value and yield a single Msg per iteration in the publisher.

Several of my generators might generate multiple output messages per input. However, the generator can only return one value per .send(input), so I return a list. Then I write a custom (sub/)pub method to iterate over the generator's return value and yield a single msg per iteration. I think this pattern can be constructed automatically by gen_to_unit.

4. For both gen_to_unit and Gen(ez.Unit), add INPUT_SETTINGS stream and corresponding subscriber method that updates settings and (re-)constructs the generator.

A few of the Units that I have refactored to use generators had this pattern already. I don't think it will be harmful to add it by default.

Overall, I don't find that I'm using Gen(ez.Unit) very much. I think its main purpose is to support inspection for code hints, which is quite useful so maybe I should use it, though I might need a GenAxArray version that uses INPUT_SIGNAL and OUTPUT_SIGNAL instead.

Thus far, I've mostly been using gen_to_unit for the simple 1-input, 1-output generators and living with my IDE not knowing what SETTINGS' fields are. For anything more complicated, I've been making my own Unit class, but not inheriting from Gen, because I have to rewrite the on_message function anyway such as in the pattern described in topic 3. above.

It seems like gen_to_unit, with the features described above, is quite a bit more powerful than what a base class can provide. Is there some hybrid solution where the SETTINGS are provided manually (so as to be inspectable) but the rest of the stream and method generation is inferred from the generator method?

[cboulay]

Note: Due to #85 , gen_to_unit has limited utility, at least until that other issue is solved. Discussion on this issue should be put on hold until then.