What would be the best way to give a module its own context and have its local variables and Modules belong to that context?
Here is an idea:
Then use this as:
This works because of the unique symbol:
Here is a version without SetAttributes
Use as follows:
Here's one approach, although I don't think it will actually meet your needs.
The main thing is that care needs to be taken to make sure symbols are created in the correct context, with context being set during parsing, not evaluation.
A quick test:
Unfortunately, since you're intending to use this for CDF or a demonstration, I expect you'll run into problems because
If each will have it's own methods, you can't avoid writing every method by hand, and, you can always precede your modules by
Or, if you are just interested in how to implement a basic ADT with some state, basic methods, getters, constructor, check this Usenet post by Leonid when he implements the Pair object, without using a context for each object.
I'm copying it simplified here
and you use it
Basically, "first" and "second" are private attributes, and he stores the state of each instance of
I've also seen around a small OOP package around that associates a class to a context, so the methods are defined in the context of the class instead of the
I recommend you to have a look at my answer here http://mathematica.stackexchange.com/a/999/66 in order to use a symbol as an object.
The idea is to use DownValues for storing properties and UpValues for storing methods.
Update: Here are two variants of edit(6) that do not require a dispatcher function.
Update2: Code updated to reflect the correct initialization in method3 of this post How to eliminate the need to double evaluate a Manipulate so that a Module in its Initialization section works?.
First one: variables comes from the Module of makeSolver, functions are stored in a solver symbol.
Second one: everything is stored in a solver symbol but assignments to part of a list stored in this symbol are not straightforward.
Honestly I found your question to be too hard to follow in all details, maybe you should try to give a short summary in the beginning. Anyway, if I understood what you want I think there is no reason to do something very complicated. It just needs a very small change to Ruebenko's first approach to avoid the need for
I tried to reprogram your example with that approach, here is the result:
I have not checked whether it passes the demonstrations site checks but I think the above doesn't use anything that could be considered dangerous. You will notice that I used strings instead of symbols for all the "fields" and "method" labels. Of course the code would look much cleaner and more standard if I'd use symbols, which can be done just as well. But I think it would make things more complicated (and need extra code) if you want them to be properly localized and all that. Another thing that's a matter of taste is whether you want to use different syntax for methods so they can be recognized easier as such (or want to pass arguments). You could just as well have used e.g.
The whole approach would of course become much more interesting when using several of such "Objects", like here:
If you see an advantage in doing so, you could of course create the "instance" symbols in an own context, but actually I think there is no reason in bothering with namespaces with that approach...
We could use one of the (many!) patterns that simulate OOP-style objects. For example, we could define a constructor function:
Then we can construct a couple of objects:
... query for properties ...
... update some properties ...
... and query in ways routine to Mathematica but alien to many OO languages: