Re: Funny situation (was: Re: Serialization et al)

[Christian Reiniger <warewolf@mayn.de>]

Pierre Phaneuf wrote:

>> The reason the FileSystemEntityContainer is a template, is that there
>> are two basic kinds of file system entities (i.e., dirs and files), and
>> these two are kept separately in two *different* containers.
>
>Why not a single container? This is a case of the composite container (I
>think this is the name, not sure) pattern. This pattern is for cases

Just "composite" AFAIK.

>where you have a tree of items where nodes and leaves share a lot of
>functionality (nodes would be directory and leaves would be files, and
>they are almost the same). You simply make the node class inherit the
>leave class and have the pointer to the root of the tree be a pointer to
>a leave. The node class would add a few content manipulation methods
>(addEntry, removeEntry) and whatever else is specific to the node.

The common functionality of both classes is adressed by deriving both from
the DirEntry interface.
Add to that the fact that we know in about 90% of the cases whether we need
a directory or a file and your solution isn't so elegant anymore.

Really, applying the composite pattern to a situation with only two
distinct types is overkill. 

>class Directory: public File {
>public:
>  [ implementation of inherited methods from File ]
>  int addEntry(File*);
>  int removeEntry(File*);
>};
>
>This makes for one simple system. There could be a asDirectory() method
>to get a properly casted Directory* or a NULL if the File is really only
>a File (similar to the S_ISDIR macro applied to the POSIX structure
>equivalent to those classes, struct stat). Or dynamic_cast could be
>used.

These little things, when summed up, make for a more complex system than we
have now. And a slower one at that :)

>Also, File and Directory themselves would only be abstract classes. File
>would have UnixFile, PakFile, ZipFile, and whatever else as childrens.

That's how it is now.

>Simple API, maps quite nicely to the underlying concepts. 10% of the
>work, and easily fixable! ;-)

Surely not 10% of the work. Rather like 110%

>> There is. FileSystemEntityContainer is both a template as well as an
>> abstract base class with all pure virtual methods. The template dictates
>> the interface, the pure virtual methods provide the implementation.
>
>Yes, but can only contain one or the other of directories or file???
>What, each directory would have two FileSystemEntityContainer, one for
>the directories it contains and the other for the files it contains? You
>call that straightforward?

Yes :+)


Right now it looks like this:

DirEntry      // interface all "File System Entities" share

File  : public DirEntry      // Abstract file representation 

PakFileFile : public File    // File in a PakFile. Concrete.

Directory : public DirEntry  // Generic directory. Cares about maintaining
                                the list of its contents. Contains one
                                HashTable<File *> and one
                                HashTable<Directory *>

PakFileDir : public Directory  // Dir in a PakFile. Concrete

HashTable<>   // "Simple" Container for several files / dirs


	Christian
-- 

Drive A: not responding...Formatting C: instead