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

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