kpreid at mac.com
Fri Mar 5 14:54:28 PST 2010
On Mar 5, 2010, at 15:55, Kenton Varda wrote:
> On Fri, Mar 5, 2010 at 9:21 AM, David Wagner <daw at cs.berkeley.edu>
> 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". 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.
[Quick response; take all blanket assertions here with a grain of salt]
Access to “the filesystem of this machine”, or rather let's say to
open(), *is* inherently a singleton; similarly “Internet access from
this machine”, “the free memory of this machine”, etc. In order to not
have singletons here, you have to add some type of subdivision (which
may be non-natural to the platform) such as “access to the subtree of
the filesystem rooted at this path”.
On the other hand, these *are* design mistakes:
* having a (public) *type* for that singleton, such that it is not
possible to substitute a different but equivalent-interface
authority because it would have the wrong type.
* having that singleton be accessed “globally” from everywhere in
the program (e.g. passing around filename strings instead of file
Kevin Reid <http://switchb.org/kpreid/>
More information about the cap-talk