Re: OOP Revisited

*To*: mathgroup at smc.vnet.net*Subject*: [mg31708] Re: [mg31697] OOP Revisited*From*: Andrzej Kozlowski <andrzej at tuins.ac.jp>*Date*: Wed, 28 Nov 2001 01:29:30 -0500 (EST)*Sender*: owner-wri-mathgroup at wolfram.com

I am one of the people who have expressed reservations the use of OOP in Mathematica though not as vehemently as Jens Kuska. I have to say however that I have recently become converted to the opposite view point. The reason is that I have become acquainted with object oriented extensions of Lisp which make it possible to deal with highly structured areas of mathematics like algebraic topology in a remarkably natural way ( <http://www-fourier.ujf-grenoble.fr/~sergerar/Kenzo/> while staying entirely in the functional paradigm. In fact similar things are done for algebriac geometry by Macaulay II (http://www.math.uiuc.edu/Macaulay2/) which is also functional and object oriented. Since I prefer Mathematica to Lisp or Macaulay III would like to be able to implement similar things in Mathematica and I hope that maybe Orestis package will make it easier. Andrzej Kozlowski Toyama International University JAPAN http://platon.c.u-tokyo.ac.jp/andrzej/ On Tuesday, November 27, 2001, at 04:47 PM, Orestis Vantzos wrote: > 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. > > >