Version 5 of private namespace

Updated 2005-03-20 09:44:26 by CMCc

It should be possible to define a private namespace such that no external references to variables are possible, and no invocation of namespace-local procs are possible except via namespace exported names.

This would provide a nice degree of encapsulation, perhaps even a cheap sandbox and would be easy to implement.

Implementation: I suggest a form of name of namespace which can't be present in a variable or proc invocation. This means an explicit namespace-path can't be constructed for a private namespace. -- CMcC 20 Mar 2005

RS: Sandboxes are for playing - I'd hate a closed box that says "hey, you cannot see or touch my sand" in interactive debugging... Also, with escaping as needed, any string can be the name of a variable or proc. In general, I'm more happy with Tcl's spirit "You can do anything you can think of, and more" as opposed to Bondage & Discipline languages that say "Good girls don't".

CMcC RS, there's a difference between license and freedom. What you seem to be suggesting is that I can do anything I can think of except establish a private namespace, and this in the name of freedom. Sandboxing is a technical term, btw.

PWQ CMC:', What is the point of this?. We have safe interpreters, can redefine every command, what would be achieved by private namespaces?. Don't you trust your own code?

CMcC a private namespace would be cheaper and lighter weight than a safe interpreter and provide some of the same facilities. Simple as that.