Parse context - class or map?

[Jukka Zitting]

Hi,

Another quick design question: Is it better to use a Map<String,
Object> for the TIKA-275 parse context, or should we have an explicit
ParseContext class for that?

The Map approach was simple to implement, but in the long term it
might be better to use a separate class as it gives us an easy way to
extend the design if needed. Also, the class approach would make it
easy to centralize things like type safety and default value handling.

This is what I had in mind:

    public class ParseContext {
        public <T> T get(Class<T> key) { ... }
        public <T> T get(Class<T> key, T defaultValue) { ... }
        public <T> void set(Class<T> key, T value) { ... }
    }

BR,

Jukka Zitting

[Michael Wechner]

Jukka Zitting schrieb:

> Hi,
>
> Another quick design question: Is it better to use a Map<String,
> Object> for the TIKA-275 parse context, or should we have an explicit
> ParseContext class for that?
>
> The Map approach was simple to implement, but in the long term it
> might be better to use a separate class as it gives us an easy way to
> extend the design if needed. Also, the class approach would make it
> easy to centralize things like type safety and default value handling.
>
> This is what I had in mind:
>
>     public class ParseContext {
>         public <T> T get(Class<T> key) { ... }
>         public <T> T get(Class<T> key, T defaultValue) { ... }
>         public <T> void set(Class<T> key, T value) { ... }
>     }
>  

do you have a concrete example?

Thanks

Michael
> BR,
>
> Jukka Zitting
>  

[Mattmann, Chris A (388J)]

Hi Jukka,

I would really like to have an explicit ParseContext class rather than a generic Map which provides little to no information as to its structure or how it will be used.

+1 for ParseContext...

Cheers,
Chris



On 11/11/09 11:33 AM, "Jukka Zitting" <jukka.zitting@...> wrote:

Hi,

Another quick design question: Is it better to use a Map<String,
Object> for the TIKA-275 parse context, or should we have an explicit
ParseContext class for that?

The Map approach was simple to implement, but in the long term it
might be better to use a separate class as it gives us an easy way to
extend the design if needed. Also, the class approach would make it
easy to centralize things like type safety and default value handling.

This is what I had in mind:

    public class ParseContext {
        public <T> T get(Class<T> key) { ... }
        public <T> T get(Class<T> key, T defaultValue) { ... }
        public <T> void set(Class<T> key, T value) { ... }
    }

BR,

Jukka Zitting


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@...
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[Uwe Schindler]

That looks very similar to our AttributeSource in Lucene 2.9/3.0 :-)

I like the type safety and coolness of the generics... :-)

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@...

> -----Original Message-----
> From: Jukka Zitting [mailto:jukka.zitting@...]
> Sent: Wednesday, November 11, 2009 7:33 PM
> To: tika-dev
> Subject: Parse context - class or map?
>
> Hi,
>
> Another quick design question: Is it better to use a Map<String,
> Object> for the TIKA-275 parse context, or should we have an explicit
> ParseContext class for that?
>
> The Map approach was simple to implement, but in the long term it
> might be better to use a separate class as it gives us an easy way to
> extend the design if needed. Also, the class approach would make it
> easy to centralize things like type safety and default value handling.
>
> This is what I had in mind:
>
>     public class ParseContext {
>         public <T> T get(Class<T> key) { ... }
>         public <T> T get(Class<T> key, T defaultValue) { ... }
>         public <T> void set(Class<T> key, T value) { ... }
>     }
>
> BR,
>
> Jukka Zitting

[Jukka Zitting]

Hi,

On Wed, Nov 11, 2009 at 11:52 PM, Michael Wechner
<michael.wechner@...> wrote:
> do you have a concrete example?

The client code for the Map option is currently:

    Map<String, Object> context = new HashMap<String, Object>();
    context.put(Parser.class.getName(), parser);
    parser.parse(..., context);

The ParseContext version would look like this:

    ParserContext context = new ParseContext();
    context.set(Parser.class, parser);
    parser.parse(..., context);

The parser implementation code in DelegatingParser.parse() is now:

    Object parser = context.get(Parser.class.getName());
    if (parser instanceof Parser) {
        ((Parser) parser).parse(...);
    } else {
        new EmptyParser().parse(...);
    }

With the proposed ParseContext it would be:

    context.get(Parser.class, new EmptyParser()).parse(...);

BR,

Jukka Zitting

[Jukka Zitting]

Hi,

On Wed, Nov 11, 2009 at 8:33 PM, Jukka Zitting <jukka.zitting@...> wrote:
> Another quick design question: Is it better to use a Map<String,
> Object> for the TIKA-275 parse context, or should we have an explicit
> ParseContext class for that?

Thanks for the feedback! I've implemented the ParseContext class in
revision 836057.

BR,

Jukka Zitting