fyi, small note on using Mathematica for object based programming

[Nasser M. Abbasi]

Just FYI,

I wrote this small note on using Mathematica for object-based
programming. I found that it works really well for me.

Nothing too advanced, just a simple way of using Module[] but
in a way to emulate object based programming that I did not know
about before.

http://12000.org/my_notes/object_based_in_mathematica/v1.html

--Nasser

[DrMajorBob]

Mathematica is already object-oriented WITHOUT all that. What a lot of
overhead for nothing.

Bobby

--
DrMaj...@yahoo.com

[DrMajorBob]

method[arg] is determined according to specific DownValues for a specific
"arg" or a general pattern for objects with the Head (or other
characteristics) of "arg". The same function or method name can be used
for many objects and classes of objects without confusion. That behavior
is, I would say, inherently object-oriented.

The opposite of object oriented is when function names must include class
names, such as integerAdd[1, 2] rather than simply 1 + 2.

Judge for yourself whether the following is simpler than the OP's code,
but I don't believe it requires mimicking C++ so closely!

methods = {index, polynomial, stiffness, mass, damping, TF,
unitStepResponse, bodePlot, poles, display};
ClearAll @@ methods
plantList = {};
plant[stiff_, damp_, m_] :=
Block[{s, t}, Module[{tf, poly, self = plant[1 + Length@plantList]},
polynomial@self = 1/(m*s^2 + damp*s + stiff);
index@self = First@self;
stiffness@self = stiff;
mass@self = m;
damping@self = damp;
tf = TransferFunctionModel[polynomial@self, s];
TF@self = tf;
unitStepResponse@self =
Chop@First@OutputResponse[tf, UnitStep[t], t];
bodePlot@self = BodePlot@tf;
poles@self = TransferFunctionPoles@tf;
AppendTo[plantList, self];
self
]]
display[any_plant] := Through[(methods[[;; -2]])@any];
new = plant[1, 1, 10];
display@new

Bobby

On Sat, 07 Apr 2012 03:34:34 -0500, Andrzej Kozlowski
<akozl...@gmail.com> wrote:

> While I completely agree with the sentiment expressed in the second
> line, I don't think the first one is true, at least not in any sense of
> "object-oriented" I am familiar with.
>
> Andrzej

--
DrMaj...@yahoo.com

[Vince Virgilio]

I like it, and it resembles a technique that I've been using for several years.

I called my version "Loom" (Lightweight Objects and Options in Mathematica). In addition to encapsulating state through convenient closures, and providing simpler syntax for option handling, it enables another level of granularity in package files. So packages can grow quite large this way (I like single-file deployments). Large packages remain easy to read with the lexical "locality" provided by Loom without burdening symbol syntax. There are no special operators---just a few infrequent keywords: 'static', 'class', and 'type'. There is provision for inheritance and upcalls which I rarely use (keyword 'super', largely untested).

Loom grew out of need in my application development; it was not forced from a desire to imitate a particular paradigm. It has proven itself over time in a variety of modeling, simulation, and analysis tasks.

But! I do not see an easy way to implement /automatic/ serialization of objects with this approach. The reliance on $ModuleNumber for pseudo-pointers
throws a wrench in it, I think.

I'm glad Nasser documented his version. Someday I might document mine.

Vince Virgilio