Hi JB
2018-01-13 7:51 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
> Hi Romain,
>
> Clearly AutoValue is really convenient for developer. It reduces the
> boilerplate of getter/setter for configuration.
>
> I'm not a big fan of an IOOptions, because it's a breaking change and I
> think we gonna loose some flexibility for developers.
>
> POJO is basically what we did before using AutoValue.
>
> A potential new option would be to do an improvement in AutoValue (on the
> annotations or the way it does the fields generation).
>
Preventing to chain them can be nice too, so would be enforcing a single
ConfigPojo for IO configuration. Would that work?
>
> Regards
> JB
>
> On 12/01/2018 19:26, Romain Manni-Bucau wrote:
>
>> Hi guys
>>
>> I'd like to discuss the IO configuration.
>>
>> My goal is to be able to instrospect (or equivalent) the IO to
>> instantiate them programmatically in a generic manner from a generic config
>> - this is not yet linked to the system property topic but can benefit beam
>> on this other topic too.
>>
>> Auto value loosing the final fields ordering is impossible to use until
>> you parse sources.
>>
>> In other words: auto value is nice for programmatic usage but is blocking
>> for any automotion on top of it - even using unsafe is not an option ATM :(.
>>
>> Can we try to get something to solve that need please?
>>
>> Here are the solutions I see (pick just one ;)):
>>
>> 1. migrate IO to IOOptions (based on pipeline options kind of design).
>> This is a breaking change - but I'm sure we can mitigate it in term of user
>> compatibility - but it unifies the beam config and enables to not have IO
>> specific configurations which can vary between the IO if not developped by
>> the same guy.
>> 2. Add an extension to @AutoValue to also generate the field names order
>> in the create() (@Fields({"address","username","password"}). Cheap but
>> the way to instantiate an IO from a config is still a pain (think
>> Factory.createIO(clazz, properties))
>> 3. Also generate a plain pojo from the abstract @AutoValue class - this
>> requires to modify the source class to make it working but is feasible with
>> a processor
>> 4. drop autovalue and use plain pojo - writing it cause it is a technical
>> option but it leads to break as much as 1 without getting all the benefit
>> to have an agnostic config and the tooling we can build on top of it
>> 5. probably others
>>
>>
>> Wdyt?
>>
>> Personally I really like 1 cause it starts to create a clean programming
>> model we can then build other features on.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> | Blog <
>> https://rmannibucau.metawerx.net/> | Old Blog <
>> http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibuca
>> u> | LinkedIn <https://www.linkedin.com/in/rmannibucau>
>>
>
