You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@frauzufall Why not just make the FooOptions object in question an @Parameter of the FooCommand, like anything else? This would be a really nice way of doing things, benefiting from the builder pattern and avoiding frequent breaking command parameter signature changes.
If MyCommand is changed to take a single MyCommandOptions parameter, we would have to think of a way of parsing the option string to create that MyCommandOptions from the given key-value pairs, no?
Activity
ctrueden commentedon Apr 20, 2020
@frauzufall Why not just make the
FooOptionsobject in question an@Parameterof theFooCommand, like anything else? This would be a really nice way of doing things, benefiting from the builder pattern and avoiding frequent breaking command parameter signature changes.imagejan commentedon Apr 21, 2020
@ctrueden wrote:
I agree this would be nice. One downside would be however that the usage from command line would be difficult.
If
MyCommandis changed to take a singleMyCommandOptionsparameter, we would have to think of a way of parsing the option string to create thatMyCommandOptionsfrom the given key-value pairs, no?frauzufall commentedon Apr 21, 2020
Wouldn't we also run into issues with the macro recorder?
I would prefer
much more than
.. but maybe that's just me. There are other places where I would enjoy having a possibility to pass options, like this:
AbstractOptions: implements Map<String, Object> #1
frauzufall commentedon Apr 24, 2020
PR #3 would allow us to do this without changing the
CommandService. It would not help with theIOService, but that's maybe a different discussion.AbstractOptions: implements Map<String, Object> #1
imagejan commentedon Apr 24, 2020
I think we can adapt the API of
IOService(or in particularTableIOService) as required to allow this usage, no?