Re: Re: Re: Re: Not quite a Swell FLOOP?
- To: mathgroup at smc.vnet.net
- Subject: [mg37527] Re: [mg37485] Re: [mg37463] Re: [mg37440] Re: [mg37430] Not quite a Swell FLOOP?
- From: "Hermann Schmitt" <schmitther at netcologne.de>
- Date: Sat, 2 Nov 2002 03:32:14 -0500 (EST)
- References: <200211010643.BAA11299@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
Hello, in my OO`System it is not difficult to program. The kind of usage is very similar to the kind Java classes and Java objects are accessed from Mathematica in J/Link. Hermann Schmitt ----- Original Message ----- From: "Sseziwa Mukasa" <mukasa at jeol.com> To: mathgroup at smc.vnet.net Subject: [mg37527] [mg37485] Re: [mg37463] Re: [mg37440] Re: [mg37430] Not quite a Swell FLOOP? > > 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
- References:
- Re: Re: Re: Not quite a Swell FLOOP?
- From: Sseziwa Mukasa <mukasa@jeol.com>
- Re: Re: Re: Not quite a Swell FLOOP?