- To: mathgroup at smc.vnet.net
- Subject: [mg31697] OOP Revisited
- From: atelesforos at hotmail.com (Orestis Vantzos)
- Date: Tue, 27 Nov 2001 02:47:49 -0500 (EST)
- Approved: Steven M. Christensen <email@example.com>, Moderator
- Sender: owner-wri-mathgroup at wolfram.com
This post is (partialy) a response to several posts in the 'Creating an object' thread. Several people, with Jens-Peer Kuska as a prime example, claimed that seeking to apply OOP(Object-Oriented Programming) concepts and methods in Mathematica programming is false. I believe that it is actualy perfectly natural to use the OOP methodology when programming in Mathematica! Allow me to elaborate: a) The whole concept of symbols is pure OOP. We have a persistent entity that caries its own data AND methods. Is that functional programming? Not realy - the fundamental Mathematica entity (the symbol) is NOT a function (in the funct.progr. sense). It looks much more like an object to me, with its Downvalues, Upvalues, etc. It may masquerade as a function, but it is much more like an object pretending to be a function(again in the functional programming sense). b) The Mathematica language contains several features which are almost pure OOP. CompiledFunction, InterpolatingFunction, NotebookObjects, etc. are refered to as objects in the Mathematica Book, and they are strongly encapsulated, in typical OOP style. c) OOP is more a way to organize large pieces of code, rather than writing code in the first place. Take C++; it is obviously procedural programming organized in classes according to the OOP spitrit. CLOS is an OOP extension to LISP, which proves in my eyes that functional and object-oriented programming are not incompatible. In general, OOP works in different scales to most other programming styles; the only pure OOP language I know of is Smalltalk, as almost every other OOP language is a combination of OOP with functional,procedural or other styles. d) Packages provide strong encapsulation(the 1st fundamental OOP concept) for Mathematica code; I don't hear anyone complaining that they are incompatible with functional programming! The whole concept of contexts (which allows organized hierarchies of symbols with similar names- hence 'dynamic method binding'-the 2nd fundamental OOP concept) provides a flexible environment which cannot be used effectively by the one-liner school of programming: the relentless nesting of functions towards a single function that solves the problem at hand. One-liners can be little gems, I admit it, but they are not an intelligent way to produce and maintain professional code. Keep them organized in classes and a different picture emerges. Functional programming works in a smaller scale than OOP, so there really is no conflict. To sum it all up, the world has moved on; OOP has been proven to be THE way to program medium to large projects. You can write your methods in functional, procedural, or rule-based style; it doesn't really matter, as far as OOP is concerned. I strongly believe that it is time for the Mathematica language to mature and establish itself as a viable(and effective) solution to scientific programming needs. And the availability of effective OOP facilities, is an important step toward that direction. Orestis Vantzos PS. I am currently working on a package that implements all the afforementioned major OOP concepts (plus inheritance ofcourse), with an eye towards seamless integration with the functional style and effectiveness both in speed and memory usage. I do intend to back my opinions, as expressed here, with code.