Re: OOP Revisited
- To: mathgroup at smc.vnet.net
- Subject: [mg31767] Re: OOP Revisited
- From: atelesforos at hotmail.com (Orestis Vantzos)
- Date: Sat, 1 Dec 2001 02:45:07 -0500 (EST)
- References: <9tvgee$fn5$1@smc.vnet.net> <9u4hgi$lq3$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
OK, let's see..
a) Mathematica is NOT object-oriented...I would not be designing the
package I mentioned in my post, if it was! It is close though; close
enough for me to consider and write the aforementioned package. Allow
me to explain (again):
b) Take a symbol called F.
Jens thinks that F is (just) a symbol.
If I define F[x_]:=x^2, now F is suddenly a function! It is a function
and a symbol (but obviously not at the same time; the fact that the
'functional behaviour' is stored in the Downvalues of the symbol F is
of no importance).
Now, I go on and define jollyWrapper[F]^=Print["gotcha!"]. Wow, F is
now a symbol again, which also knows how to behave when nested inside
the infamous jollyWrapper! I know, I know, it's just that jollyWrapper
is an old fashioned function which just happens to know what to do
with F; no OOP here. Well, if I Clear[F], jollyWrapper has forgotten
everything! It seems that F was the perpetrator after all.
Now, what do you call something that behaves like F? Is it a function?
As far as I can tell, definitions of the type head_[args___] are
technicaly NOT function definitions, eg. they are not 'remembered' by
some central 'function-meister'. They are 'transormation rules'
directly associated with the symbol 'head'. Now, we all agree that
functional programming (+rules+patterns) is the natural way to think
of Mathematica programs. It is a powerful metaphor indeed. But it pays
to remember that 'inside Mathematica' there are NO functions! 'Inside
Mathematica', trees of symbols are transformed according to rules
associated with corresponding symbols.
The evaluation of head_[args___] could be visualized as 'asking the
symbol head to transform the subtree {args}, according to its
transformation rules(Downvalues[head])'. Technicaly, it would be more
justified than saying 'apply function head to arguments args'. If
symbol 'head' doesn't know what to do, well then we can kindly 'ask'
the first argument in {args} to check its Upvalues. Etc., etc.
Remember the old Mathematica motto: 'Everything is an expression'?
It pays to remember that 'expression' means 'tree of symbols' and
Mathematica seems to believe that 'symbols are responsible for the
transformations' (Clear,Remove,Downvalues and Upvalues prove that). I
know that some people will say this is all about coding efficiency (so
that relevant transformation rules can be found quickly and
accurately), but it's stil there and it sounds like OOP. Symbols make
up the data(expressions), yet they seem to hold the methods as well(in
transformation rules form). Why ignore that? Ignoring the actual
evaluation mechanism and insisting on 'Everything is a function' is
throwing away vital information about Mathematica; thinking of symbols
as 'objects' can help you use it to your advantage.
c) So are symbols 'objects'? In the object-based programming sense(as
in object-oriented databases), yes; in the OOP sense, not quite
(although they certainly look more like objects, than functions). OOP
is all about organizing objects in certain ways, and Mathematica does
not implement these (encapsulation excluded, due to packages). Jens is
fairly ironic, when he asks whether 'objects are symbols or packages'.
I try to describe a 'natural way' to map OOP concepts into familiar
Mathematica concepts. So if symbols are akin to objects, then packages
are akin to classes. Lots of things are missing; inheritance and
dynamic binding being the basic ommisions. But if one sits down and
implements these facilities, one ends up with something that IS a
class, yet it is very similar to a Mathematica package! The missing
distance is not large; moreover, I claim that packages emerge as a
powerful (and essential) feature when 'completed' in this way. They
don't have to be a simple 'book-keeping' device..
d) OK, Orestis, so we have to do everything the OOP way; do we throw
our Mathematica Book out the window or what?
Not realy (throwing the Mathematica Book out your window is dangerous,
by the way ;-). I am very surprised that Jens disagrees on the 'OOP
works in conjunction with other styles' subject. He is a hell of a C++
programmer; we all know that (I have spent dozens of hours happily
spinning 3D stuff on his kick-ass visualization package). Does he
think of for-loops in C++ in OOP terms? Is 3+4 actualy 'object 3
receives a + message with object 4 as an argument'? I don't think so;
C++ is procedural C with a light OOP sauce. Smalltalk(and clones) is
the only example I am aware of, that is completely object-oriented.
Java & C++ are partly procedural to name 2 famous examples. CLOS is
(you'll never believe it) both functional AND OOP!!
When (or rather if) you install my OOP package in your HD, what you
basicaly get is a new way to write packages. Think of something like
BeginClass[..], EndClass[] plus friends. These 'special packages'
know all about inheritance and dynamic binding and all that. They are
classes, and if you feel like it, you can create 'instances' of them;
symbols that use these classes like large 'Downvalues reservoirs'. If
you 'dissect' these packages, what you find inside is not 'OOP
mumbo-jumbo', but good old-fashioned functional programming; or good
old-fashioned procedural programming. Or good old-fashioned
whatever-it-is-you-put-in-your-packages programming. There are rules
you want to follow, if you want your 'class' to be a proper OOP class,
but they do not change the familiar Mathematica notation. Your methods
will still be written in functional style, in all probability.
e) I do not seek to convert the Mathematica community to an 'OOP
cult'. One of Mathematica's strengths is the wide range of programming
styles it offers. I have seen half a dozen implemented:functional,
procedural, rules-based, string-based, logic, genetic, cellular
automata, you name it. I am just adding one more style to the
afore-mentioned. You can use it or you can ignore it. Your choice.
Orestis