Re: OOP Revisited

*To*: mathgroup at smc.vnet.net*Subject*: [mg31740] Re: OOP Revisited*From*: Jens-Peer Kuska <kuska at informatik.uni-leipzig.de>*Date*: Thu, 29 Nov 2001 00:14:24 -0500 (EST)*Organization*: Universitaet Leipzig*References*: <9tvgee$fn5$1@smc.vnet.net>*Sender*: owner-wri-mathgroup at wolfram.com

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. Yes, it is handy to define a print-Method for every Symbol, it is simple to define for a symbol the operator Plus. > Is that functional > programming? Not realy - the fundamental Mathematica entity (the > symbol) is NOT a function (in the funct.progr. sense). The fundamental Mathematica entity are atoms (like Symbol, Real, ...) *and* functions with head_[arguments___] > 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). Thanks to your investigations it turns out that symbols are objects ! A symbol is *not* a function (i.e. an expression hea_[arguments___]) -- it is a atom. Expand is a Symbol Expand[] is the function. You can use 2*Expand - Expand/N + Exp[NDSolve] and 2Expand -Expand will simplifyed to Expand How 2*Expand - Expand/N + Exp[NDSolve] masquerade a function ? > 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. So what ? Are the symbols objects or the values of the symbols ? Is the "Notebook" symbol an object or is Notebook[Cell["Exceptional nonsense","Text"]] the object ? Can you please so kind to find out what your objects are ? And if I say a=Notebook[Cell["More nonsense","Text"]]; what is the object ? The symbol "a" or it's value ? Can I cast "a", that is a Notebook[] object, into a Real by saying a=2.0 ? When the "Mathematica Book" say "object" it means a thing that is an expression but this expression has not traditional mathematical equivalent. > c) OOP is more a way to organize large pieces of code, rather than > writing code in the first place. In other words, OOP organize code without writing it ? OOP is a way to organize *data* and the access to structured data. This concept is not very usefull for a language that knows nothing about data types. > 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; Oh yes, a "very strong encapsulation". One of the first things that MathGL3d does, when it starts up, is to patch the ThreeScrip` package. The PNG Import/Export does the same, it patches the "strong" encapsulation of the System`ConvertersDump`exportToBitmapConverter[] function to export images with 16 bits per channel and to save an alpha-channel. I love this "strong encapsulation" -- it does not exist at all. > 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) Huuuuhhh, the next version of "what objects in Mathematica" ? Now the contexts are objects ? A function like Graphics`ContourPlot3D[] is now a method ? a method of what kind of data ? Don't tell me it is a method of Graphics` because it produce a Graphics3D[] expression. Can you explain where is the hierarchie of symbols in packages ? How does Graphics`Arrow` is related to Graphics`ArgColors`. And how can I overload the functions of Graphics`Arrow` with BeginPackage["Graphics`Arrow`LongArrow`"] EndPackage[] This does not cause Mathematica to load the package Graphics`Arrow`, none of the functions defined in Graphics`Arrow` are defined ! How do you bind a dynamic method with help of contexts. > 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. If you ever written a larger pice of code in LISP, the very first thing you learn is to make a huge number of small functions -- otherwise you get lost in parentheses. > 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. Who has proven that ? OOP has some advantages when you are programming graphical user interfaces. > You can write your > methods in functional, procedural, or rule-based style; it doesn't > really matter, as far as OOP is concerned. Unfortunatly I can't write methods in Mathematica, because I have no data types, that declare that methods. But I can write *functions* that act on any pattern of parameters. > 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 what happens the last 13 years ? before you discover the objects in Mathematica ? What happens if it turns out that our objects (symbols, the values or the contexts) are no objects at all ? Will Mathematica become less powerfull ? less effective ? The well thought concept of Mathematica is it's genial pattern matching. That's why it *is* the solution for scientific programming needs since 1988 and Version 1.0. > And > the availability of effective OOP facilities, is an important step > toward that direction. OOP typical make the programms slower and *not* more effective. > 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. Regards Jens