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=