Re: MathOO: Adding Object Orientation to Mathematica

*To*: mathgroup at smc.vnet.net*Subject*: [mg113701] Re: MathOO: Adding Object Orientation to Mathematica*From*: Tang Ross <ph.tchaa at gmail.com>*Date*: Mon, 8 Nov 2010 03:39:23 -0500 (EST)*References*: <ib38rs$f0j$1@smc.vnet.net>

---------- Forwarded message ---------- From: Tang Ross <ph.tchaa at gmail.com> Date: Sun, Nov 7, 2010 at 10:14 PM Subject: [mg113701] Re: MathOO: Adding Object Orientation to Mathematica To: Leonid Shifrin <lshifr at gmail.com> Lastly, I have checked. Module scope returned variables will garbage-collected automatically. The reason of my case that it is not collected is because of downvalue. In:g[x_] := y = x Module[{x}, g[x]; Print[x]; x= 1] Out: x$526 In: FullDefinition[y] Out: y = x$526y Attributes[x$526] = {Temporary} x$526 = 1 In: y = 1; In:?x$526 Information::notfound: Symbol x$526 not found. >> In this case, when y doesn't reference x$526, it is removed immediately. Therefore, DownValue holds a reference to the symbol, which I think is not reasonable. Regards, Ross voofie.com On Sun, Nov 7, 2010 at 10:04 PM, Tang Ross <ph.tchaa at gmail.com> wrote: > Thank you very much for your long and informational reply, Leonid. > >>general problems of mixing of immutable (well-supported) and mutable (not so well-supported) styles of programming, > > Would you mind elaborating more on this? I am not sure if I get it or not. > > You can do this in MathOO, > > a = new[Object][]; > a.b={1,2,3}; > a.b[[3]]=5; > a.b > > Out: {1,2,5} > > Is this one the mutable issues..? Anyway, I probably get it wrong. > Please tell me. > > For the garbage collection issues, I think it can't be solved at this > moment. That's why you can see, the command of creating new object is > "new". In C++, you need to delete it on your own. Furthermore, when I > am running programme in Mathematica, I just don't care about clearing > the used variables. Even if I do so, I found that Mathematica kernel > needed to be restart from time to time since the memory consumption > just grows larger and larger. > > For the features you mentioned, > 1. fast dispatch > 2. inheritance / polymorphism, > 3. good integration with other constructs in Mathematica language > 4. compatibility with Compile > 5. fast automatic garbage collection > 6. good module / package system > 7. IDE (Workbench) support - field and method name completion, > 8. certain coding and documentation standards > 9. introspection capabilities (in the style of Java reflection) > 10. perhaps some code base (libraries) written in OO style > > Now, the speed of MathOO is about ten thousands attributes access per > second, and funciton call a bit less. See the benchmark articles. > http://voofie.com/content/174/benchmarking-your-mathoo/ . Please help > me to benchmark in your computer if you are interested too. > The point is, there isn't much improvement left for the performance. > Therefore, it is strongly recommend to avoid using "." operator in a > loop. > > e.g. If a is an object, b is a method, > > c = a.b > Do[c[x],{n}]; > > Use a temporary variable to store the method, and it will called with > the instance of a automatically. > > 2. Since Python style OO is used, inheritance / polymorphism is > already supported. The method resolution order is using C3, which > should be better to the depth first resolution. > > 3. I am not very sure it MathOO is able to to that. I have override > some methods, like Definiton, so that you can see the definition of > object, class more easily. > > 4. compatibility with Compile is quite impossible. Since MathOO is > dynamically typed. Like: > > a.b.c[x] > > a.b can be any other type of objects. Without finding its value in run > time, it is impossible to infer where to look for c, whether it is an > attributes(with downvalues), an object function, a class function, or > the class parents' method. It is a general problem for dynamic typed > language including Python. Since I aimmed to support most of the > Python OO, therefore it is impossible to do. > > 5. Mentioned before. Users need to delete object manually. It won't > trouble much people maybe? Since you can keep mathematica running for > a period of time as long as you have enough memory. > > 6,10 good module / package system. I have plans for this. But it all > depends if the reception of MathOO is good or not. If there are enough > people willing to contribute and write classes and package, I will > open source MathOO. The package system maybe like this: > > In: Import[UnitTest] > > Then Mathematica will look for the package locally. If it cannot be > found, it will look up on the repository server, and download the > package. > > 7. I have no idea of how to support it with IDE, or any name completion. > > 8. This shouldn't be difficult to design. But if there will be any one > using, or even any people like MathOO, it is another problem. > > 9. It can be supported, but needed time. Probably in later time. > > Thank you again. I hope you may download the package and give it a > little try. I hope you may give me your valuable feedback. > > Best Regards, > Ross > voofie.com > > > > > On Sun, Nov 7, 2010 at 8:17 PM, Leonid Shifrin <lshifr at gmail.com> wrote: >> Hi, >> >> It is not a bug (AFAIK). As long as you return the Module-scoped symbol,= it >> will not be garbage-collected automatically. >> Take a look at my posts in these threads if you will, for a discussion o= f >> some similar topics: >> >> http://groups.google.com/group/comp.soft-sys.math.mathematica/browse_thr= ead/thread/ec4958c35f99758d/ >> >> http://groups.google.com/group/comp.soft-sys.math.mathematica/browse_thr= ead/thread/b2ddf61da56b0be9 >> >> Generally, I don't see any automatic way to solve this problem - you wil= l >> have to write such a garbage collector >> manually, which will cause another level of overhead on top of the >> Mathematica evaluator. And it is not even clear >> to me how to do that reliably, since, if you want to integrate your OO l= ayer >> with the rest of Mathematica >> langauge, you will have to allow your objects to be entagled with other >> constructs, which you will not be able to >> make reporting to you whether they reference a given object or not. For >> example, if you pass a list filled with >> your objects (references) to some function, how do you know when it stop= s >> referencing them? Most of Mathematica functions >> create copies of their arguments and work on or return these copies, and >> that would mean also creation of copies >> of references to your objects, and you have no control over this process=

**Re: MathOO: Adding Object Orientation to Mathematica**

**Re: MathOO: Adding Object Orientation to Mathematica**

**Re: MathOO: Adding Object Orientation to Mathematica**

**Re: MathOO: Adding Object Orientation to Mathematica**