Re: [boost] [Boost.utility]

Subject: Re: [boost] [Boost.utility]
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-01-26 14:53:02

Jeff Flinn wrote:
> Stewart, Robert wrote:
> > Jeff Flinn wrote:
>
> > 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?

What else is the point of Singleton?  It is for common access to a single, global object.

[snip diatribe insinuating that any use of global state versus FP approach is bad design.]

> > 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.

That's incorrect.  The thread was discussing *using* Singleton to access global state.  It wasn't about determining *whether* a function is dependent upon global state.

> >> 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.

It seems quite concrete to me.  I'm not sure how I can make it less abstract for you.  It is a Singleton instance of a class that manages the application configuration data.

> 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

The configuration data is managed by a class with accessors of various sorts for the data.  Some of the data structures are ad hoc, in that they apply specifically to the hive of data representing the configuration data, but they are not just tossed together in an arbitrary way, just to make things work (which is what most people think "ad hoc" means).  The class encapsulates a great deal, enforces many invariants, and has a great deal of behavior.

So much for your contention.

> 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?

Absolutely yes, when those extra arguments are otherwise a few, well-known Singletons.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.