[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
Prev by Date:
**Re: Virus Warning for email by Tomas Garza**
Previous by thread:
**Re: OOP Revisited**
Next by thread:
**mathematica on os x**
| |