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