Services & ResourcesWolfram ForumsMathGroup Archive

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

Re: Re: Re: Not quite a Swell FLOOP?

• To: mathgroup at smc.vnet.net
• Subject: [mg37485] Re: [mg37463] Re: [mg37440] Re: [mg37430] Not quite a Swell FLOOP?
• From: Sseziwa Mukasa <mukasa at jeol.com>
• Date: Fri, 1 Nov 2002 01:43:12 -0500 (EST)
• Sender: owner-wri-mathgroup at wolfram.com

On Thursday, October 31, 2002, at 04:41 AM, Alexander Sauer-Budge wrote:

> Object-Oriented Programming (OOP) is certainly more than just data
> encapsulation, a feat which modular programming performs just fine.
> Probably not the definitive reference, but FOLDOC's definition of OOP
> <http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?object-
> oriented+programming> mentions both encapsulation and inheritance.
> Furthermore, OOP does not imply a particular syntax. For example,
> "myinstance.mymethod(args)" and "mymethod(myinstance,args)" are both
> perfectly legitimate OOP syntaxes.
>

The FOLDOC definition is good but I prefer to refer people to the 
Object Orientation FAQ at http://www.cyberdyne-object-sys.com/oofaq/.  
As has been pointed out encapsulation already exists in any modular 
language, Mathematica has it through contexts, if you use header files 
correctly C has encapsulation, so do Modula, Ada and nearly any other 
language developed since 1970.

Inheritance is a sticky subject.  It derives (no pun intended) from 
system design considerations but in practice it is closely tied to 
attempts to increase code reuse in strongly typed, static, imperative 
languages.  Note that Mathematica has none of these qualities.  See 
section 1.7 of the OO FAQ for a cogent discussion of inheritance.  
Since everything in Mathematica is of the same type: an expression and 
in the most general case a function can take any expression as an 
argument there is little need for inheritance in Mathematica.  Instead 
Mathematica programmers can force inheritance structures by restricting 
function arguments to a particular pattern in which case the pattern 
could be considered to define a type and if the pattern is 
appropriately designed as Alexander did in his examples then we could 
consider a hierarchy of types to which the function applies thus 
getting an inheritance tree.

The biggest gain in my opinion from OOP is neither encapsulation, which 
has existed nearly as long as high level languages have been known, nor 
inheritance which necessarily exists in languages with pattern matching 
facilities such as Prolog and thus also has been known to programmers 
since long before the current OOP craze.  The main facility for code 
reuse is polymorphism which in my opinion is closely related to 
inheritance but obviously is not identical, see section 2 of the OO 
FAQ.  Again, Mathematica has always supported polymorphism through the 
possibility of a function having multiple downvalues.  However the 
downvalue and pattern matching mechanism together are more akin to 
parametric polymorphism.  Here is where I show myself to be a heretic: 
parametric polymorphism and encapsulation are all you need for OOP, 
inheritance is unnecessary.  If you define an appropriate set of 
polymorphic functions then your inheritance hierarchy will be 
implicitly defined.  I admit that this is an extreme view.

> One of the primary benefits of OOP is that you can subclass
> pre-existing classes, _without modifying or recompiling_ the existing
> class code, and objects designed for the superclass can use the
> subclass without knowing it. This greatly facilitates the REUSE of code
> and increases the flexibility of libraries.

And ultimately that is the goal: a small flexible library.  However I 
will repeat my heresy, you can either design an elaborate inheritance 
hierarchy and specialize methods from the base class as you descend or 
equivalently you can define a set of types (or patterns although the 
two are not exactly equivalent) and an appropriate set of functions on 
those types.  From the design perspective the former method seems 
preferable, for implementation however the latter seems to me to be 
more effective.

> The pervasiveness of the OOP paradigm has made it seem somewhat like
> "the one true way to structure a program," but I think a moments
> reflection leads most people to concede that, while wonderful, it is
> not a panacea (e.g. the Standard Template Library for C++ is less OOP
> and more functional programming).

Or functional programming (with patterns/guards or strong typing) is 
more OOP than we realized.

> Of course, there are other ways to this, but this is just an example of
> simple and natural way to provide basic data inheritance with method
> specialization in your Mathematica programs.
>

Is it just me or does this resemble the Common Lisp Object System?  Is 
that a coincidence?  I have always believed that Mathematica possessed 
the necessary facilities for OOP the problem is the amount of 
programmer effort necessary to program in an OOP style with 
Mathematica.  So it seems some kind of syntactic assistance is all that 
is necessary: functions to allow easy definition of constructors, 
destructors, class relationships etc. and easy inspection of the same.  
My guess is that the end result will closely resemble CLOS but given 
the protest most programmers make when faced with the LISP paradigm I 
think many Mathematica users would be unhappy with the end result.

Regards,

Sseziwa

• Follow-Ups:
  • Re: Re: Re: Re: Not quite a Swell FLOOP?
    • From: "Hermann Schmitt" <schmitther@netcologne.de>