Guido van Rossum
Fri, 07 Mar 2003 12:41:16 -0500
[Moving a discussion about capabilities to where it arguably belongs]
> The point about capabilities is that mere possession of a capability is
> all that is required to exercise it. If you start adding security
> checkers to them, then you don't have capabilities anymore. But the
> point is somewhat deeper that than - given capabilities, you can
> implement proxies without requiring any more infrastructure - you can
> also implement security schemes that don't really correspond to any kind
> of security checking at all (ok, you can probably find some convoluted
> way to achieve the same effect, but I'll bet it comes down to having
> tokens that correspond to proxies, and security checkers that allow you
> to proceed if you have the appropriate token - in other words,
> capabilities, but very hard to use).
> So, it seems to me, its simpler and more powerful to start with
> capabilities and build proxies on top of them (or whatever alternate
> scheme you want to build).
> Once more, my apologies for not just getting straight to the point.
> BTW, if you would like to explain why you don't think bound methods are
> the way to go on python-dev, I'd love to hear it.
It seems to e a matter of convenience. Often objects have many
methods to which you want to provide access as a group. E.g. I might
have a service configuration registry object. The object behaves
roughly like a dictionary. A certain user may be given read-only
access to the registry. Using capabilities, I would have to hand her
a bunch of capabilities for various methods: __getitem__, has_key,
get, keys, items, values, and many more. Using proxies I can simply
give her a read-only proxy for the object. So proxies are more
Before you start saying that we should use capabilities as the more
fundamental mechanism and build proxies on top of that: as you point
out, we already have an equivalent more fundamental mechanism, bound
methods, which is equivalent to capabilities. It's just that raw
capabilities aren't very usable, so one way or another we've got to
build something on top of that.
--Guido van Rossum (home page: http://www.python.org/~guido/)