Re: MathOO: Adding Object Orientation to Mathematica
- To: mathgroup at smc.vnet.net
- Subject: [mg113700] Re: MathOO: Adding Object Orientation to Mathematica
- From: Tang Ross <ph.tchaa at gmail.com>
- Date: Mon, 8 Nov 2010 03:39:12 -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:04 PM
Subject: [mg113700] Re: MathOO: Adding Object Orientation to Mathematica
To: Leonid Shifrin <lshifr at gmail.com>
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 of
> some similar topics:
>
> http://groups.google.com/group/comp.soft-sys.math.mathematica/browse_thread/thread/ec4958c35f99758d/
>
> http://groups.google.com/group/comp.soft-sys.math.mathematica/browse_thread/thread/b2ddf61da56b0be9
>
> Generally, I don't see any automatic way to solve this problem - you will
> 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 layer
> 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 stops
> 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.
> Alternatively, you either keep the
> garbage collection manual, or put severe restrictions on how your layer can
> be used with other Mathematica
> constructs. Either alternative makes it much less attractive.
>
> Regarding OOP in Mathematica in general, there have been several attempts to
> introduce it,
> including probably the very first one by Roman Maeder (package classes.m).
> Any of these do not seem to
> have really taken off, in terms of wide adoption of the techniques by the
> significant part of the community.
> I think there are several reasons for that, one being the above issue with
> garbage collection and general
> problems of mixing of immutable (well-supported) and mutable (not so
> well-supported) styles of programming,
> another one being that functional and rule-based programming constructs are
> just more powerful. I think this
> essay is a pretty good account on OOP as seen by a functional programmer:
>
> http://www.paulgraham.com/noop.html
>
>
> Yet another one is that the problems for which OOP is beneficial and those
> which are usually solved with
> Mathematica are two almost disjoint sets (one particular area where I find
> OOP-like approach to be very beneficial
> even in Mathematica is GUI programming, the main reason probably being that
> UI-s are inherently stateful). If you
> have a project that seriously requires both I would rather split it into the
> OO part and computational part, and use
> hybrid Java/Mathematica or Python/Mathematica development rather than trying
> to do the OO part from within
> Mathematica. I worked for a while as a corporate Java developer and
> appreciated very much things like inheritance,
> polymorphism, interfaces and abstract classes, OO design process etc, but
> big part of it was because Java
> language is both statically typed and is lacking many useful abstractions.
>
> That said, I would certainly appreciate an OOP layer in Mathematica for some
> problems, if it is implemented
> well. What I would like to see in such implementation would be fast
> dispatch, inheritance / polymorphism,
> good integration with other constructs in Mathematica language,
> compatibility with Compile, fast automatic
> garbage collection, good module / package system, IDE (Workbench) support-
> field and method name completion,
> certain coding and documentation standards, introspection capabilities (in
> the style of Java reflection), perhaps some
> code base (libraries) written in OO style, a few more things perhaps. I
> toyed with this idea a few
> times, but making all this work seems a daunting task to me. But, of
> course, good luck anyway! In any case,
> this can be a very interesting project.
>
> Regards,
> Leonid
>
>
>
>
> On Sun, Nov 7, 2010 at 1:12 PM, ph.tchaa at gmail.com <ph.tchaa at gmail.com>
> wrote:
>>
>> On 11=E6=9C=886=E6=97=A5, =E4=B8=8B=E5=8D=885==
E6=99=8258=E5=88=86,
>> "ph.tc..=
>> . at gmail.com" <ph.tc... at gmail.com> wrote:
>> > I have written a Mathematica package: MathOO, which adds object
>> > orientation capability to Mathematica. It is currently in beta
>> > version, 1.0b. It allows you to use syntax very similar to Python,
>> > which is very easy to use.
>> >
>> > http://www.voofie.com/content/169/mathoo-adding-python-style-object-o.=
..
>> >
>> > Please read the above link for more information.
>> >
>> > You may discuss about it usinghttp://www.voofie.com/concept/MathOO/
>> > in Voofie as well. Thank you.
>>
>> In developing the MathOO package: http://www.voofie.com/concept/MathOO/,
>> I encountered a problem with Mathematica.
>>
>> The problem is, I would like to have garbage collector, so that user
>> don't have to explicitly deleting the object after using it. For
>> instance:
>>
>> NewClass[Object1]
>> Object1.$init$[self_]:= Return[];
>>
>> In the above two lines, I just defined Object1 to be a new class, and
>> the constructor to be an empty function. If you are familiar with
>> Python, you should see the similarity with __init__().
>>
>> To instantiate an Object1, I do:
>>
>> object1 = new[Object1][]
>>
>> The output is:
>>
>> Out: object$13
>>
>> Here, object$13 is an temporary variable. What I want is, when there
>> are no references to this temporary variable, it should be deleted
>> automatically. But it doesn't work as expected. I have identified the
>> problem to be the following:
>>
>> In: y = Module[{x}, x[1] = 2; x]
>> Out: x$117
>>
>> In: FullDefinition[y]
>> Out: y = x$117
>> Attributes[x$117] = {Temporary}
>> x$117[1] = 2
>>
>> Since y holds a reference of x$117, so x$117 is not removed yet. Now
>> let's delete the reference by setting the value of y to 1:
>>
>> In: y = 1;
>>
>> However, x$117 is still here:
>>
>> In: Definition[x$117]
>> Out: Attributes[x$117] = {Temporary}
>> x$117[1] = 2
>>
>> But I expected the variable to be removed since it is no longer
>> referenced. From the manual of Mathematica, it said:
>>
>> Temporary symbols are removed if they are no longer referenced:
>>
>> So, is it a bug of Mathematica? Or is there any workaround methods? I
>> am using Mathematica 7.0. Thank you very much.
>>
>
>