On 2019-08-14, Matt Sicker wrote:
> Yes, I think you understand us. A strategy pattern with default sensible
> strategies to choose.
Done now.
I'm going to tweak the implementation a little more but the API of
ExtraFieldParsingBehavior seems to work quite well.
Thanks
Stefan
We all understood each other in a brief email thread, remarkable! :-)
Gary
On Wed, Aug 14, 2019 at 9:00 AM Matt Sicker wrote:
> Yes, I think you understand us. A strategy pattern with default sensible
> strategies to choose.
>
> On Wed, Aug 14, 2019 at 06:08, Stefan Bodewig wrote:
>
> > On
Yes, I think you understand us. A strategy pattern with default sensible
strategies to choose.
On Wed, Aug 14, 2019 at 06:08, Stefan Bodewig wrote:
> On 2019-08-13, Matt Sicker wrote:
>
> > The enum makes sense. Are there any feasible ways to, say, configure
> > some sort of handler class that
On 2019-08-13, Matt Sicker wrote:
> The enum makes sense. Are there any feasible ways to, say, configure
> some sort of handler class that can implement logic around unknown
> fields?
Not really. The only extension point here currently is plugging in your
own implementations of ZipExtraField via
Hi Stefan,
I like having predefined behaviors in the enum but it does not seem to
allow for extension. I am wondering if we would be better served by using
an interface invoked by a callback mechanism where predefined
implementations exist for the enum values you now have. I would see in
The enum makes sense. Are there any feasible ways to, say, configure
some sort of handler class that can implement logic around unknown
fields? Sort of an extensibility model there, but hopefully without
having to extend ZipInputStream or anything like that.
On Tue, 13 Aug 2019 at 14:01, Stefan
