Boost logo

Boost :

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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at