[Date Index]
[Thread Index]
[Author Index]
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.
>
>
>
Prev by Date:
**Re: integral function**
Next by Date:
**Re: mathematica on os x**
Previous by thread:
**OOP Revisited**
Next by thread:
**Re: OOP Revisited**
| |