Re: Funny situation

[Christian Reiniger <warewolf@mayn.de>]

Pierre Phaneuf wrote:

>And Directory contains DirEntry*. That is right?

No. It contains containers for File * and Directory *.

>of another subclass of DirEntry would not have a set of methods
>returning Directory* and another set of methods returning File*, we
>agree?

Having seperate methods for getting Directory* and File* (one each) is a
*feature*. Because we usually know beforehand which one we need. Having
these methods makes it easy to do this and adds compile-time type safety,
storing File* and Directory* seperately makes it fast.

>Adding a third subclass would mean major breakage. Major *unwarranted*
>breakage might I add.

If you take my definition of Directories/Files in the other mail then it's
obvious we won't need a third subclass ;)
(really - it's highly unlikely that we'll need one).

>How do you go from a DirEntry to a Directory? I assume here that having

We don't :)

>> It *is* RTTI. It's not static in the way Bjarne meant it: He was talking
>> about compile-time checked type safety. This quite clearly is not what
>> AsDirectory() does.
>
>Blargh. "return this" is pretty static to me. Just as "return NULL" in

No. It uses run-time type checking, aka dynamic type checking.

>The File class isn't data. There is no read() or write() method, is
>there? Where IS the data then? I see none.

There *are* File::Read () and File::Write (). It's just not in the publicly
code in ftp, only in my own tree ;)

>friends! Now, if dynamic_cast is evil, I wonder what friend is! :-)

Er, something (almost) required for iterators??

>Oh shit. GetFile/GetDir/GetEntry. This doesn't look good at ALL. So if I
>want to add another subclass of DirEntry, I have to modify DirEntry. So
>nice. You know that you'll (unnecessarily) break vtable compatibility
>and require a recompile of client applications? Doing it with

Client apps never, ever see DirEntry. They *only* see the ppf* functions.


	Christian
-- 

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