Mathematica 9 is now available
Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2001
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2001

[Date Index] [Thread Index] [Author Index]

Search the Archive

OOP Revisited

  • 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 <steve@smc.vnet.net>, 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.


  • Prev by Date: Re: inverse function computation
  • Next by Date: Re: Dimensional analysis, Infinite sums
  • Previous by thread: Re: bisection method
  • Next by thread: Re: OOP Revisited