Re: [boost] Re: Re: [filesystem] Operations predicates

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-05-05 15:45:41

From: "Beman Dawes" <bdawes_at_[hidden]>
> "Iain K. Hanson" <iain.hanson_at_[hidden]> wrote in message 
> news:1115224522.14534.633.camel_at_dev-ihanson.ct.uk.videonetworks.com...
> > On Wed, 2005-05-04 at 10:36 -0400, Rob Stewart wrote:
> >> From: "Beman Dawes" <bdawes_at_[hidden]>
> >
> >> How about this instead:
> >>
> >>    struct shallow_status_t { };
> >>    extern shallow_status_t shallow;
> >>
> >>    status_flag status(path const &); // follows
> >>    status_flag status(path const &, shallow); // doesn't follow
> >
> > I marginally prefer the separately named functions because behavioural
> > differences to me say separate functions names whereas overloads imply
> > semanticly the same but with different types.
> 
> That rationale is convincing enough for me.
> 
> >> (It occurred to me that including the term "symlink" is limiting
> >> since not all OSes have "symlinks" that have (at least partly)
> >> analogous concepts.  That means naming the function
> >> "symlink_status" is similarly limiting.)
> >>
> > I think symlink is a fine name and whether an overload or separate
> > function names the function returning info on a symlink is going to be
> > meaningless on a platform that does not have the concept.

I disagree.  The normal function say to return information on the
path or, if it is a symlink, on the object to which it refers.
On a system without symlinks, there's no "or."  If you avoid the
word "symlink" in the function name, and follow the "shallow"
scheme I suggested above, whether there is any sort of forwarding
mechanism in the underlying OS (Windows has some bizarre,
half-baked notions of that sort), then the shallow version can
return information on that forwarding object, if possible.  Thus,
I'm advocating at least renaming symlink_status() to
"shallow_status" to avoid the nomenclature problem.

If the underlying OS has no forwarding mechanism, then a shallow
status request is a normal status request.

> I'd prefer to think use of symlink_status() on a platform without symbolic 
> linas ensuring that the code will be portable to other operating systems, 
> and to future versions of the current operating system.

You lost something in that paragraph.  I'm not quite sure what
you were trying to say.

> As an aside, I read recently a description of the next version of Windows, 
> and it sounded somewhat like they might be adding symbolic links. Hard to 
> say, however, as it was a marketing rather than technical description.

No doubt it will be yet another addition to the strange beasts
they already have, none of which will do what *nix has done for
how long?

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;