Re: rebase / STL set patch

[Robert Collins <rbcollins at cygwin dot com>]

On Wed, 2002-07-31 at 22:44, Jason Tishler wrote:
> 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.  

Yes. You have two occasions where the data related to rebasing is
transformed - disk to memory, and memory to disk. In both cases, the
data has an identical structure (not low level like [inisection] vs
inisection: + tabs, but rather high level structure: it has files and
each file has a datestamp, memory regions and rebase flags.)

> 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.

The file layout is known at two places - yes. However: note that
serialisation and deserialisation are very different. It's trivial to
ensure that one writes in a given format, less trivial to read it. You
could address this percieved encapsulation issue by implementing
rebaseIniParser within RebaseIniBuilder. 

The key point is that you *should* be able to (copy and check for
errors) a rebase.ini file simply by
RebaseIniParser("rebase-old.ini",
RebaseIniBuilder("rebase.ini")).process();

Reading into memory then becomes
RebaseIniParser("rebase.ini", myRebaseMemoryBuilder).process();

The point of a Builder pattern is to define a language without defining
a storage mechanism. Specific serialisations of that language are
encapsulated from the object representation. The gang of four example,
of a text layout Builder being driven by specific parsers for Tex, RTF,
ASCII shows this quite clearly. What they don't address is serialising
the resulting laid out text - back to (say) PostScript or PCL. You may
need a different language in that example to build a (PostScript or PCL)
output, but in our situation we can reuse the same language - that is
the Builder interface.

Let me list what classes know what:
RebaseIniParser: Understands reading the file syntax. May have a flex
and or bison toolkit linked into it. Can direct any 'RebaseBuilder'.
RebaseMemory: The Singleton. Can direct any 'RebaseBuilder'.
RebaseIniBuilder: Understands writing the file syntax. Can be directed.
RebaseMemoryBuilder: Can be directed. Understands the in memory
structures.

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

Recursion: See "Recursion".

I think you got sidetracked :}. Seriously, at first glance what you
raise *is* an encapsulation issue. However: It's only an issue because
we are special casing the code: We are choosing to output the exact same
format we are inputting. 

Let me demonstrate: Imagine that you are adding some fields to the ini
file format. You need to:
Output the new fields.
Understand both the old and the new file formats when reading the file.

With the model I'm proposing that becomes trivial:
* In the v2 parser detect a v1 file and call that parser instead, with
the same builder we were given.
* Make a v2 parser by copying the v1 parser and changing as needed.
(Yes, variations on a them can be done here - a single parser with some
magic, or other tweaks).
* Change the IniBuilder class to write in the new format.
* If needed, extend the Builder interface to support the new
functionality.

:].

Attachment: signature.asc
Description: This is a digitally signed message part