Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!ccu.umanitoba.ca!herald.usask.ca!alberta!brazeau.ucs.ualberta.ca!unixg.ubc.ca!ubc-cs!uw-beaver!zephyr.ens.tek.com!uunet!pdn!myrddin!tct!chip From: chip@tct.com (Chip Salzenberg) Newsgroups: comp.lang.c++ Subject: Re: About Lists and things... Message-ID: <286B7C68.511A@tct.com> Date: 28 Jun 91 18:13:59 GMT References: <18982@prometheus.megatest.UUCP> <2865E7A8.179A@tct.com> Organization: TC Telemanagement, Clearwater, FL Lines: 37 According to pjg@daedalus.osf.org (Paulo Guedes): >In article <2865E7A8.179A@tct.com> chip@tct.com (Chip Salzenberg) writes: >> >> Never design code that requires downcasts. >> Or, in other words: if the static type is important, why worry >> about regaining it? Don't lose it in the first place. >> > >[...] > >Now, the problem: when I lookup an object by name >obj = open ("someName") >what type should open return ? Yes, I can see how an NIHCL-like safe-downcast trick would be appealing in this case. However, there are alternatives. One alternative is to allow for the generic open, but also to have filetype-specific open() calls: FsObject *FsDir::open(const char *); FsFile *FsDir::open_file(const char *); FsDir *FsDir::open_dir(const char *); FsSem *FsDir::open_sem(const char *); A pitfall of this approach is the race condition between finding the type of a directory entry and the call to the appropriate open_xxx() function: the target object could disappear or be replaced, perhaps with an object of another type. On the other hand, a locking feature (something like FsDir::lock() and FsDir::unlock()) would solve this problem, and would also prove useful for other situations. -- Chip Salzenberg at Teltronics/TCT , "I want to mention that my opinions whether real or not are MY opinions." -- the inevitable William "Billy" Steinmetz