[cap-talk] Capabilities in C# (revised)

Sandro Magi naasking at higherlogics.com
Sun Nov 5 08:47:44 CST 2006

Karp, Alan H wrote:
> Aaah.  Now I see.  This is the kind of ambient authority you're talking
> about.  Nevertheless, the typographic convention of a leading capital
> letter means that we're not thinking of these things as normal objects.
> I wonder if you can make use of that to make your point.  

I tend to view static class methods as methods on the singleton class
type; it models the behaviour closely, and it keeps C# and the .NET VM
fully object-orientated (even if not in an entirely pleasant fashion).

After further thought, I've realized that the global accessibility is
only way to solve the real problem though. File.Open(...) is just a
function, and as long as it's restricted to using only its arguments or
whatever is accessible via other singleton types, there is no problem.
The real problem is with constructors that call out to the OS to augment
authority as you hint at below.

> The thing to ask is where the reference to FileStream comes from.
> However, you know your audience better than I.  Such a discussion might
> just confuse them.

Seems to me that the authority comes from the OS, as these APIs are
generally just a thin wrapper around the OS API. Ok, so the OS doesn't
provide sufficient controls on this string->file stream conversion (and
it's not an object-oriented interface), so it forces us to invent the
controls in the VM, hence code access security (CAS).

Perhaps the best way to explain this is an example of the way the VM<->
OS interface should be done in lieu of these global functions; you would
at least have to reify it in an object of some sort, either a single

public interface FileStreamMaker {
  Stream FromPath(string path);

Or perhaps from a safe file system API:

public class File {
  Stream GetStream();

> Valid point, but you did have to introduce the new concept of ambient
> authorities.  

I had thought that the concept of ambient authority was more fundamental
and inescapable, but perhaps I'm wrong on that. I may just be misusing
the term. That's why all this feedback is so great. :-)


More information about the cap-talk mailing list