[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Funny situation
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
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.
Drive A: not responding...Formatting C: instead