Re: [boost] Re: Name checking in filesystem

From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-12-07 21:23:11

At 12:14 PM 12/4/2004, Pierre-Andre Galmes wrote:

 >
 >I am new in Boost Filesytem and my involvement is related to one of my
 >courses.  As a project, we have to  a request for change and we can then
 >submit our "contribution" by posting it on the list. The first part of
 >my work was to analyse a request. The second part is this post. The
 >analysis can be found on the following link
 >(http://perso.efrei.fr/~galmes/boost/name_check.html). It explains which
 >is the problem in detail using examples.
 >
 >The request is the following : The automatic name checking
 >functionality, in the Boost library is turned on by defaults. That means
 >the Boost::filesystem will check for "portable" paths. The question is
 >then, should the "name check" functionality be turned on by default ?
 >Which between portable_name, native and no_check would be the best
 >choice ?  This mail is divided in three parts. The first one expose the
 >conclusions drawn from the analysis. The second part is the
 >argumentation of the results.
 >
 >The last part is composed of some suggestions after having spend some
 >hours going through the library. I apologize for the length of this post
 >and hope that it will help to improve the boost::filesystem library.

Because of the length of the post, I'll probably spread the reply over 
several messages.

 >
 >
 >I - The results
 >
 >Here is what I found out from that analysis (which should not be big
 >news :-):
 >
 >- by default the "no_check" option seems to be the best.

I'll comment on this later, although I agree with you that no_check is 
best.

 >- "native" would be the best once it supports multiples filesystem
 >checks. It may then be a good idea if this kind of check is going to
 >work in Boost 1.33 !
 >
 >Suggestions to improve the "usability" of the library :
 >
 >- the name "native" is not so explicit and tends to confuse users.
 >- How the "native" option works could by explained in an
 >   "easy-to-understand" way in the documentation.

The second path constructor argument "name_check checker" actually passes 
two pieces of information - the checker to use and the format to be 
allowed. By combining these into a single argument, the interface is 
hopefully a bit easier to use, although at the cost of being a bit harder 
to understand.

So when "native" is specified, it is really saying (1) allow the native 
(rather than portable generic) path format, and (2) possibly saying that 
some general name checking that would apply to any native formatted path be 
performed.

Note that the path being represented does not have to actually exist, and 
even if it does exist that could just be happenstance. So what kind of file 
system (FAT, ISO 9660, etc.) is involved isn't something that a path object 
knows about.  (The operational functions are where we might add a function 
that queries the actual type of the file system.)

 >I - Argumentation
 >
 >The automatic name checking functionality can behave in many different
 >ways, and from those, only three could be used as default values :
 >
 >     * portable_name : check if the path is "portable" (default on   	
 >       boost-1.3.2).
 >
 >     * native : check if the name is valid for the OS being used to
 >       execute the program.
 >
 >     * no_check : does not perform any check.
 >
 >We will then try to show which of those is the best. For this, I try to
 >make an "objective" analysis trying to quantify the choices. This is a
 >way to try to solve the problem but might not be the best one : it is a
 >lot of explanations and may just get rid of most of the readers ;).

My usual approach is to first look for "killer arguments". These are 
arguments which are so strong that they overwhelm other analysis. Peter 
Dimov has been helping a lot in the "killer argument" department as regards 
error checking.

But if no killer argument is found, then how should a decision be reached? 
Your approach of assigning weighted values to pros and cons is something 
that I used to try a lot, but have given up on in recent years. I think 
that weighting schemes just end up justifying what I thought anyhow, so 
just are rationalizations for what I was going to do anyhow. So what I do 
now is to let the choices bubble around in my mind (often overnight), and 
then pick the one that seems strongest. I also give weight to the views of 
experienced designers; thus Peter's views carried a lot of weight even 
though I disagree with some of his detail reasoning.

I've run out of time tonight; I'll try to comment further in the next day 
or two.  Good luck with your course!

--Beman