[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Funny situation

Christian Reiniger wrote:

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

As I mentioned, I find one loop with an if more elegant than two loop
without any if, but this is purely subjective. They both can be made
just as fast.

> > How do you go from a DirEntry to a Directory? I assume here that having
> We don't :)

Why the GetEntry() method in Directory then? This is one method that
confuses thing for someone trying to read that code. You might easily
get the idea that File, Directory and Entry are three *separate*

Interestingly, the Add method for File does not check if there is a
Directory with that name, and vice-versa, so they *are* separate
namespaces in the current FTP version (you can add a File called "foo"
and a Directory called "foo" without any error, if you do a
GetEntry("foo"), you'll get the File. Funny.).

I guess this is a bug.

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

Could be. I'd say method invocation in ObjC, Smalltalk or Perl would be
more like my idea of dynamic type checking, but whatever. I think the
AsDirectory() approach is safer and more static than doing a GetType on
the DirEntry and casting, that's for sure.

> > 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 ;)

And what do they do? Is there an open method? The same object is reused
to do the access? Hmm, I smell some unnecessary state here, but what the
heck, if this is internal...

> > friends! Now, if dynamic_cast is evil, I wonder what friend is! :-)
> Er, something (almost) required for iterators??

Yeah, *almost*! :-)

Goto is also almost required for a few things... ;-)

I personally do iterators as inner classes, but I also do not use them
much these days (because of the work I do).

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

No way to get the C++ API for a client? I didn't expect that...

Pierre Phaneuf
Ludus Design, http://ludusdesign.com/
"First they ignore you. Then they laugh at you.
Then they fight you. Then you win." -- Gandhi