Re: Design for a file system library

From: dylan_nicholson (dylan_nicholson_at_[hidden])
Date: 2002-03-11 18:01:59

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 08:50 PM 3/10/2002, dylan_nicholson wrote:
> 
> 
> Many of those O/S properties are constants, not variables, so don't 
present 
> the same set of problems.  The existence of a file (and even 
whether it is 
> a file or directory, since that may change unexpectedly too) is in 
effect a 
> global variable; that's why error handling is so important in this 
and 
> other I/O related libraries.
> 
Currently logged-in user is not constant under most modern OS's, nor 
is active window, nor is the environment, nor is current 
directory...etc. etc.
And why is the existence (or indeed the contents) of a file an "ok" 
global variable to access/modify, but current directory not?

> 
> It isn't just me that is saying "global variables considered 
harmful."  It 
> is the whole software engineering establishment. Wulf and Shaw's 
paper of 
> that name is considered one of the great papers in computer 
science.  See 
> http://bit.csc.lsu.edu/~chen/GreatPapers.html
> 
I can't seem to find that paper anywhere online, although I'm very 
much interested in reading it.  As it it I agree that 90%, maybe even 
95% of global variable uses are best avoided, and all global data 
should be used with extreme caution.  But I honestly can't believe 
too many people have seriously thought about what *no global data at 
all* implies.  Even functional languages have implied global data 
(for instance calling 'print' prints to some implied globally 
available output device).

>  >Just like typos and cliches :o)  I'm not sure what you define as a
>  >Global variable.  Global data is essential in most large scale
>  >applications and libraries, provided it's managed sensibly (ie no
>  >direct access).  If you literally had to pass all the information 
you
>  >ever needed around as function parameters I would give up 
programming
>  >tomorrow.
>  >Btw have you ever used cin, cout or cerr?
> 
> And the global state issues are well-know; Boost just added a new 
library 
> to help deal with that problem.
> 
Which library is that?  But my point is, let's say my application 
uses several 'global' resources:

* files in the current directory
* standard output device
* standard input device
* standard error device
* a log file
* environment variables
* an event dispatching table that keeps track of objects that recieve 
certain events
* the current user id
* configuration files specifying locations for various resources 
* current user preferences for the font/colour/size of GUI widgets
etc. etc.

Are you suggesting that *ALL* this information should be passed to 
every function that might ever need it (including obviously functions 
that don't need it directly, but make use of others that do).  

Dylan