Hi Roberto, we want to be as typesafe as we can so specifying narrow types and having classes that hold configuration options in specific fields. That might not be a good approach for Any23 if it has numerous options that need to be set and having to maintain this over time becomes cumbersome.
Here's something you can think about: if you find that the values in those Maps or Lists need to be parsed from Strings to other types to configure Any23 then it's probably better to introduce a class to hold those values so no conversion is needed. There's no need to add another layer on top of Any23, if there's a Configuration class in Any23 that ends up being created from the Map<String, String> it would be better just to use it instead of the Map. If the extractors List is a list of object instances or classes it would be better to narrow that list to List<ExtractorInterface> or List<Class<ExtractorInterface>>. Hope this helps, zoran On Fri, Jun 28, 2019 at 12:08 AM Beto Flores <[email protected]> wrote: > > Hi all. > > I am working in adding configurability to the Any23 DataFormat creation > through DataFormatClause. > > I was thinking in two polymorphic forms like these: > > marshal().any23(conf, extractorsList).... > marshal().any23(conf).... > > Where conf would be a Map<String, String> containing Any23 Configuration > parameters as Key-Value pairs. And extractorsList a List <String> > containing a list of active extractors to be used by the dataformat. > > But I noticed that other dataformats do not use complex structures (Map, > List) in DataFormatClause, instead they use simple types such as int, > String, boolean. Is there a specific reason for that?, I mean it is a > standard to use only simple types. Am I going to have trouble in the any23 > Reifier implementation if I use the aforementioned approach?. > > Best, > Roberto. -- Zoran Regvart
