commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <>
Subject Re: Immutable builder pattern for parsers?
Date Sun, 12 Feb 2017 11:39:13 GMT

On 09/02/17 04:02, Peter Ansell wrote:
> Not all fluent configuration APIs are "builder patterns". By that I
> mean that you can have a "return this" convention for the builder with
> mutable fields without it building or cloning new objects.
> A builder pattern is characterised by a terminal method returning a
> new instance of an object, avoiding the archaic multiple-constructor
> pattern. It is also generally fluent, but there is no requirement that
> a builder be fluent. There is also no requirement that the result of
> the build() method be fully immutable. I.e., in this case, it could be
> a parser object with mutable parsing state, even though its
> configuration fields are likely to be immutable.
> You can do all of that without a difficult to define and implement
> "clone" method, and without reconfiguring multiple builder objects in
> the same way.
> For example, your code could change to:
>      JenaRDFParserFactory factory = new JenaRDFParserFactory()
>          .contentType(RDFSyntax.TURTLE)
>          .target(g1);
>     factory.parse(Path);
> where .parse is a terminal method that creates a new parser object and
> parses the given "Path" immediately, without the typical build method.
> However, you could also support a "build" method. The reason for
> naming it a Factory is to make it obvious that you aren't setting
> methods on an actual parser, just setting up for one. In this case the
> parser itself is only an internal object, and may not even be on the
> I am not sure how the Future fits a specific use case though, as it
> would not return an actual result, as the results are emitted into the
> graph as directed by .target(g1). Not everyone wants parsing to spawn
> off a new task/thread, particularly if they have maximum latencies to
> maintain for service level agreements, and threads may not be able to
> be consistently spawned within those time frames.

parse as a terminal makes sense to me. Maybe setting source and 
destination at the point of parsing.

A parser (presumably we are talking streaming parsers) is a process that 
takes an InputStream and has a handler for results.  The 
XRDFParserFactory does not have to set the source and destination though 
it may be useful to be able to as an additional feature layered over the 
the top of the basic operation of parse(src, dest).

Much the same for Future - that's one model for parsing but it's quite 
natural to do it synchronously as well.

I guess my real question is what it the lowest level abstraction you are 
aiming for?

(I didn't get from the javadoc is source() can be called multiple times 
and if it is, what happens - e.g. prefix and blank node labels).


... feeling inspired to do try this for Jena because of
     recent requests ...

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message