[cap-talk] Singletons Considered Harmful

[David Barbour]

On Wed, Mar 31, 2010 at 8:54 PM, Ben Kloosterman <bklooste at gmail.com> wrote:
> Instead of singletons especially for logging a form of IOC/Dependency
> injection may be appropriate to inject a reference to a logging class and
> remove the global it does come with a code understanding overhead though.  I
> suppose the logical parallel to this IOC/DI container is the power box a
> small piece of trusted code.

Or you could use dynamic scope - a hidden set of extra 'context'
parameters passed along with every message unless explicitly blocked.
In this sense, it's close to thread-local storage... excepting that
each callee logically has his own 'shallow' copy. A logger capability
may be embedded into a dynamic scope, such that any callee that wishes
to do so may emit to that logger.

Dynamic scope makes for a much more extensible language, albeit at
risk to static type safety and one's ability to analyze objects in
terms of type signatures.

One can put a lot of interesting things into a dynamic scope:
process-accounting purses, distributed transaction information, error
or trace loggers, resumption policies for exceptions, certificates or
other offline rights-amplification tokens, powerboxes, sealed values
for edge-to-edge out-of-band communications (useful when a framework
needs upgraded but you can't make it happen), and so on.

So long as the default dynamic scope is empty, and assuming one has
the ability to extract the current 'value' of the dynamic scope and
replace said value wholesale, it doesn't pose any risk to capability
security, and still allows reasoning about confinement. While dynamic
scope does inherently mean violating POLA (because a lot of objects
will have access to capabilities they don't need in that dynamic
scope), it doesn't hinder any *local* reasoning about POLA.

And, of course, it will cover about 99% of anything that would ever
make you pine after ambient authority.

Dave