MathGroup Archive 2010

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: MathOO: Adding Object Orientation to Mathematica

  • To: mathgroup at smc.vnet.net
  • Subject: [mg113697] Re: MathOO: Adding Object Orientation to Mathematica
  • From: Leonid Shifrin <lshifr at gmail.com>
  • Date: Mon, 8 Nov 2010 03:38:38 -0500 (EST)

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.
>
>



  • Prev by Date: Re: FFT in mathematica
  • Next by Date: Re: MathOO: Adding Object Orientation to Mathematica
  • Previous by thread: Re: MathOO: Adding Object Orientation to Mathematica
  • Next by thread: Re: MathOO: Adding Object Orientation to Mathematica