Re: rebase / STL set patch

[Jason Tishler <jason at tishler dot net>]

Rob,

On Wed, Jul 03, 2002 at 08:44:03AM +1000, Robert Collins wrote:
> How does this approach sound:
> Use the Builder pattern to build the in memory representation. Use a
> second Builder pattern to build the on-disk representation. This is
> similar to your original design, but without the encapsulation issues.
> It's an improvement over the memento approach in the same respect, but
> may take a little more effort.
> 
> i.e. we feed a stream into a parser that understands the syntax (you
> could review the parser pattern, but I think that is overkill for
> this). That parser uses a builder to generate the in memory database -
> and which other parts of setup can use if they have specific
> requirements (i.e. if foo is not relocatable, they call into the
> builder). Then at the end the in memory database is given a Builder
> and a stream for the builder, and calls into it to save the file. NB:
> the two builders will have the same abstract parent.  (say
> "RebaseBuilder" is a parent of "RebaseIniBuilder" and
> "RebaseMemoryBuilder").
> 
> What do you think?

If I understand the Builder pattern, then I don't think that it is a
good fit for the rebase configuration file design.  You suggest that
RebaseIniParser is the Director and RebaseMemoryBuilder is the Builder
above -- this part is congruent with the Builder pattern.

However, you also seem to suggest that RebaseMemoryDatabase is another
Director.  I thought that the Builder pattern uses a single Director to
drive multiple Builders.  Additionally, now knowledge of the
configuration file syntax is known by both the RebaseIniParser and
RebaseIniBuilder classes which breaks encapsulation.

What do you think of my critique of your critique of my critique...? :,)

Thanks,
Jason