On Jul 20, 2020, at 17:14, Jeff Laing <jefflaing@...> wrote:
You really haven't provided enough information about the caller, and you've skipped over the C programmers favourite answer.
Presumably you actually NEED all those seperate selectors and can't just change the caller to call a common handler.
Second, what's wrong with:
#define IMPLEMENT(m) -(mytype)parse##m { return [self parse:m]; }
IMPLEMENT(XYZ)
IMPLEMENT(ABC)
Thanks for the idea… it might be a good choice… as for additional details.
The caller can be seen as a controller. It dynamically allocates model (parser) classes based on context.
The model classes define the -parse### that are available by implementing a protocol (for consistency). So, all of these selectors are already accessible in an array of dictionaries returned by the model.
The controller then asks the model for it’s available parsers and the iterates over them -invoking each one, collects a cumulative Status, and provides an overall result.
So, the selectors are already defined In this array, then I have to implement each one as a method which is one line: red two nested calls, with a constant. So, 99% the same, save the context (constant) of which parse method is being invoked. Historically these methods were not one line. But parsing newer data formats (XML) leaves less individualized code in each parse method.
Now, I can’t change this design, there’s no justifiable gains from that. I do have the opportunity to rethink how the components of this design are stitched together for this new model, and would like less unnecessarily redundant code, if the cost of achieving this is not too great.
I hope these additional details are helpful…
Thanks,
Sandor
