object oriented mathematica programming

Question

I was wondering how to do it in general, what are the best strategies etc. I have seen some solutions and some of them look really hard/tedious to use. The one I worked on used pure functions to implement object functions and heads like OBJECT[]. It was very hard to use on the class coding side. I got dizzy when defining functions and constructors (especially the inheritance part was tough).

So the emaphsis of my quesiton is on the elegenace of the coding part of a class. Ideally, I am looking for something that would work as follows. First, we define a class, e.g. car as follows:

beginClass["vehicle"];
   public startTheEngine;
   private fuel;
   vehicle[args_]:=Block[{},...];
   startTheEngine[thrust_]:=Block[{}...];
endClass

beginClass["car", "vehicle"];
public TurnTheRadioOn;
private frequency;
car[args_] := Block[{...},];
TurnTheRadioOn[]:=
   Block[{},
      use private variable frequency
   ]
endClass;

Please note that it is very important that private/public functions are defined almost as in a "normal" mathematica code. This would the main requirement so to say.

The class would be used as

car1 = newObject["car", args];
car1.StartTheEngine[];
car1.TurnOnTheRadio[];

I am curious what is that one has to think about? To consturct something like the above probably involves many aspects of Mathematica, e.g. how would one fix the "." syntax etc. If you suggest an existing package I would be grateful if you could comment on how it works in principle.

My naive expectation is that the encapsulation part could be fixed by BeginPackage constructs. All objects could be stored in namespaces specifically designed for each class. I presume that objects would look like

car1 = OBJECT["car"][fuel$1,frequency$1,....];
car2 = OBJECT["car"][fuel$2,frequency$2,....];

I presume one would have to construct something like a compiler that would convert the class definition code above into the class .m file. Also, to some extent, the second main issue is how to construct such a compiler.

Regards Zoran

p.s. The reason why I am asking this is that I really had a need for something like this many times.

Answer 1

The Mathematica language is optimized for the symbolic programming paradigm, and provides the most leverage and convenience when one stays within that paradigm. Object-oriented programming is a significant departure from the symbolic paradigm, and one ends up having to write most of the supporting infrastructure from scratch. There is nothing inherently wrong with that, of course, but it would be much less effort to exploit the J/Link facility and write OOP code in Java. The Wolfram Workbench makes it easy to mix Mathematica and Java code.

It would be fruitful to think about what requirements are driving one towards an OOP solution. The question suggests that the interest is in how to simulate structure types, but perhaps there are other concerns like encapsulation and polymorphism. It seems there is scope for some more specific follow-up questions along the lines of "What is the Mathematica equivalent of the object-oriented idiom X?".

OOP Considered Harmful?

Within the context of Mathematica, object-oriented programming might even be considered harmful. OO emphasizes the creation of "black box" objects whose internals are inaccessible to outside callers. While this has obvious benefits for complexity control through information hiding, it does fly directly in the face of the power of symbolic programming. Mathematica emphasizes synergy between seemingly unrelated components by allowing the symbolic representation of one to be transformed into the symbolic representation of the other. A "black box" does not play well in this ecosystem. As a concrete example, contrast the difference between Graphics "objects" and the new V8 Graph objects. The latter take a somewhat OO approach -- generating some negative feedback in the community.

None of this is to say that OO is intrinsically harmful. The point of this discussion is that OO is foreign to the Mathematica ecosystem and that by taking that design choice, one might rule out some desirable synergies in the future. Take that decision consciously.