Re: [boost] [Boost.utility]

Subject: Re: [boost] [Boost.utility]
From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2010-01-26 14:18:19

Stewart, Robert wrote:
> Jeff Flinn wrote:
> 
>> I fail to see the analogy between global-state-coupling and
>> exceptions.  In the former, you've got a function with
>> dependency upon global state, and any function that calls
>> that function is now dependent upon global state. The only
>> way I can tell that dependency is I have to hunt that down
>> by looking at the source code, or trying to link and getting
>> an unresolved ref liner error. How are exceptions similar?
> 
> Let me try another way to explain my point.
> 
> In the case of return codes, you must litter every function in the call chain with the appropriate return type.  Each function in the chain must examine the returned value to determine whether to proceed or return an error.  With exceptions, intermediate functions are ignorant of the exceptions thrown or the code that handles them.

I'm aware of the effects of return codes vs exceptions.

> With Singletons, code that needs access to global state accesses a Singleton.  Without that, all intermediate functions must be littered with argument(s) for the state needed by the inner function.  If the inner function needs access to global state it didn't need before, or no longer needs access to global state it once did, all functions in the call stack must be changed to pass or not pass along that state.

Isn't your first sentence exactly defining singleton abuse... using a 
singleton as glorified global data access?

The major tenet that affords functional programming it's power and 
robustness is that a function depends only upon it's arguments. The Law 
of Demeter provides the extension for OO that member functions are 
allowed to depend upon it's object's(this) state and it's arguments.

What makes the singleton's functionality so different from any other 
arguments or object data members that you don't want to make them just 
as visible? Yes, system's change, that's why there are refactoring tools 
and IDE's. If you find  yourself with such a brittle system, fix the 
design. If you just want a quick and dirty hack en lieu of proper 
design, I guess you can use global data access, but don't dress it up as 
anything but the hack that it is.

Open the back door and let chaos to ensue.

> I was never discussing determining whether a function is dependent upon global state.

That's how the singleton has been used in this thread AFAICT.

>> What use cases do you see where global state access is required?
> 
> Consider an environment with a single configuration state object.  All code requiring access to that configuration state can either access it as global state, which it is, or that object can be passed to all functions that require it.  The latter leads to polluting myriad other functions with arguments they need only to satisfy the functions they call.

That's not a very concrete use case. I contend that this "single 
configuration state object", really isn't an object. It's just an ad hoc 
collection of data with no encapsulation, no enforceable class 
invariants, no behavior. The singleton usage pollutes any functions that 
use it with a myriad of types that aren't relevant to their 
responsibilities. Are you saying that getting rid of "arguments they 
need only to satisfy the functions they call" at the expense of 
increased hidden coupling is a more valid design decision?

Jeff