From: ilv2fly2001 (mcr_at_[hidden])
Date: 2002-01-30 11:05:11
--- In boost_at_y..., "Stewart, Robert" <stewart_at_s...> wrote:
> From: ilv2fly2001 [SMTP:mcr_at_y...]
> >
> > > Perhaps that means we need a simpler, lower level class that
> > > manipulates a pathname or some portion of one, using a single
> > > case sensitivity/filesystem policy, and another, higher level
> > > class, that aggregates the simpler objects to create a logical
> > > pathname object that spans filesystems.
>
> [snipped description of facet-based I/O of a path components
> collection]
>
> That's the sort of thing I was alluding to, but there's still the
> need for the lower-level, somewhat more platform specific pathname
> manipulations.
>
> IOW, I'd still want to be able to write code that starts with a
> pathname-in-a-string like "some relative path/subdir/another
> subdir/filename.suffix" on the systems I use, even if that is
> parsed into some internal format and managed by cross-platform
> code thereafter.
>
Absolutely, you should be able to do that, but it would be handled by
a facet not by the container.
What I was trying to suggest was that the container delagated all of
its input/output through a facet. So, you could still make use of
your pathname-in-a-string but as you pass it to the container it runs
off to the assigned facet to parse, validate, normalize, and break it
into the individual components.
Going in reverse and taking path components from the container would
involve an output facet that would give you a component like 'foo/'
or '/' or 'textfile.txt' depending on what component you where asking
for.
IOW, all the smarts needed to work on a platform specific basis are
in facets (probably some policy based design) not the container. The
container itself enables you to access the individual parts
positionally and hides all the gory details of using the facets from
the library user.
I'm probably not being as clear as I could be, I'm typing this up
inbetween meetings and nonstop office interruptions.