[cap-talk] Singleton discussion (was: Re: object-oriented-security.org)

[Jed Donnelley]

On 3/5/2010 12:55 PM, Kenton Varda wrote:
> On Fri, Mar 5, 2010 at 9:21 AM, David Wagner <daw at cs.berkeley.edu 
> <mailto:daw at cs.berkeley.edu>> wrote:
>
>     Object capabilities are often understood to include the following:
>
>      * A design practice of building abstractions with encapsulation.
>      * Programming on a platform (e.g., language, OS) that is free of
>       ambient authority.
>      * Ensuring that access to all security-relevant resources can be
>       done only via unforgeable references (capabilities).
>
>
> My point here is that your latter two points (which seem like the same 
> point to me) really boil down, in OO terms, to "don't use singletons".

For anybody else who might not have been following the "singleton" 
discussion, these references were useful for me:

http://www.oodesign.com/singleton-pattern.html
http://en.wikipedia.org/wiki/Singleton_pattern

I assume that's what the discussion is about?

> As it turns out, there is now widespread agreement among OO 
> programmers that singletons should not be used.  The problem is that 
> most platform libraries (designed before people understood the dangers 
> of singletons) still expose the filesystem and other resources as 
> singletons.
>
> For people who already agree that singletons are bad, it should not be 
> that hard to convince them that they should use a platform API that 
> avoids singletons, and perhaps even a programming language that bans 
> them.  Once they do that, they're now writing capability-based code.

Is there anywhere I can find a review of how different programming 
languages "deal" with this singleton pattern?  From the wikipedia 
reference above it appears that there are many languages where the 
singleton pattern can be programmed.  Perhaps it would be worthwhile to 
note (e.g. on the above Wikipedia page) which capability oriented 
languages "ban" them, how, and the consequences?

--Jed  http://www.webstart.com/jed/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20100309/2999810a/attachment.html