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

[Bjarke Hammersholt Roune <asmild@post6.tele.dk>]

> > I agree here. The solution I detailed at the end of the E-mail you
> > responded to abstracted out implementation details like the fact that
> > Paks use a hashtable. A directory for a zip could transparently use any
> > kind of algorithm and representation.
> 
> You had a good start in that implementation, I just didn't have enough
> time to completely cover it this time. Some things were still off-base.
>
My english isn't perfect. Off-base means ... ? Sub optimal?

> I don't exactly see why it is a template. The entries should be
> abstracted as well, so no need to make this class generic, it will take
> entries of the abstract class.
>
You lost me here. It will take entries of the abstract class? You mean
like it will "take" (i.e., contain) the abstract class for a file or a
directory? If you do, then, that's possible within the scheme.

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.

Of course, it would be possible to devise an interface and
implementation for FileSystemEntityContainer that would make it possible
for it to meet the requirements of both being a container for dirs and
files, without being a template. However, that would require
compromising compile time type safety in favor of runtime type safety.
This is bad both in terms of efficiency and bug tracking.

FileSystemEntityContainer being a template isn't all that bad, as we'll
probably only be making two different instantiations of it (one for
File, and one for Directory).

> The requirement just after the
> "FileSystemEntityContainer is a template" one is one requiring that the
> entries should have some specific methods, this only reinforce this.
>
Reinforce what?

> There should be simply an abstract class with those methods as pure
> virtual, simple and straightforward.
>
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.

> I didn't understand one point completely clearly, but the general tree
> of directories representing the filesystem itself and the directory data
> in the archive are mostly unrelated. For example, an archive file format
> might not have any tree structure, but only provide a string as a key to
> get a file information, and that would be sufficient. At archive loading
> time, you would read all of the string keys and by simply interpreting
> them as pathnames, build up the general tree of directories representing
> the filesystem.
>
That would be possible in the current scheme. The corresponding class to
PakFile for this format is free to implement itself in any way it seems
fit. It could build the file system iteratively. A Directory derivative
is free to implement the abstraction of a directory any way it wants,
including how to serialize. Code in a Directory derivative could take
care of serialization. FileSystemEntityContainer derivatives are free to
implement themselves in any way they see fit, including how to
serialize. Code in a FileSystemEntityContainer derivative could
implement the serialization.

They could also all cooperate, if that is the best way to do it. The
point is that there is a major amount of flexibility here, and you
should be able to find a solution for just about any problem you may
have without altering the basic structure and interface of the abstract
base classes.

> > Excuse my ignorance, but I really don't have a clue as to what NFS
> > (filesystem?), IDL or RPC is.
> 
> NFS is Sun's Network File System. IDL is Interface Definition Language,
> [...]
> compatible way, and the NFS layer compatibility will just come through.
>
Thanks for clearing that up for me.

> The LISP version, if it would be translated directly in C, would be
> recursive too, but why it is called iterative anyway is that a LISP
> compiler is normally smart enough to transform this into an iterative.
> C/C++ compilers don't optimize over function/method boundaries (except
> for inline stuff, of course).
> 
Isn't that a weakness in compilers rather than in the language of C/C++
itself? I get the hint that its more tricky implementing this in C/C++
(or compilers would do it), but still, I don't believe its impossible,
just very hard.

> > It all comes down to skill, and how many programming problems you've
> > solved in the past (ie, experience). For me, that list would be quite so
> > extremely very very small. You obviously have a much larger experience
> > than I, so even if the problem may seem almost non-existent to you, it
> > takes me a little while to create a solution that both have a sound
> > design and works the way its supposed to.
> 
> Sorry, but I am a very bad teacher, I tend to assume that everyone has
> similar experience to myself... I may sound a bit rude at time, but I
> don't mean it.
>
Don't worry, I'm not very prone to thinking people are trying to be rude
towards me.

I've noticed that when people really are trying to be rude over E-mail,
it'll be so blatantly obvious that its completely impossible to miss. It
usually goes something like "You suck", "man, you're a retard" or
"You're dumb as a door". That kind of stuff. I usually just assume that
anything less is a miscommunication of some kind. I'd say it works
pretty well, as I to my knowledge haven't been wrong ever when using
this "algorithm" :)

> > Anyways, the issue wasn't really serialization, but proper design.
> > That's a thing that it is certainly worth spending some time on.
> 
> Yes. What you are trying is fringing on more advanced serialization.
> In-place edition of streams containing serialized objects is not
> trivial. Partial deserialization is also non trivial. The StrList
> example I gave you is particularly specific to those two problems, since
> they are the real ones you'll have to face. "Ordinary" serialization is
> much simpler.
>
> The StrList example simplifies its workings by dividing the task into
> two classes, one that is mutable (StrListWriter) and the other that is
> read-only (StrList). The mutable one is much less efficient than the
> read-only one, but it doesn't matter, since the string lists are used
> read-only all the time except for their initial creation.
> 
I'll definitely take a look at this. Thanks again for point it out.