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

Re: Re: Not quite a Swell FLOOP?

• To: mathgroup at smc.vnet.net
• Subject: [mg37463] Re: [mg37440] Re: [mg37430] Not quite a Swell FLOOP?
• From: Alexander Sauer-Budge <ambudge at MIT.EDU>
• Date: Thu, 31 Oct 2002 04:41:42 -0500 (EST)
• Sender: owner-wri-mathgroup at wolfram.com

Your visualization sounds fun. As far as programming paradigms for  
implementation, I have a hopefully helpful suggestion on structuring  
your implementation.

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.

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. What amuses me is that the  
wild popularity of OOP seems to be _partly_ due to the "new OOP  
languages" having better module systems (than C, for example) as well  
as a syntax which encourages the use of modularity, and _partly_ due to  
people finding the metaphors of OOP helpful in structuring their  
thinking.

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). One of the difficulties of OOP's  
pervasiveness is that it is the only paradigm many people know, so when  
they approach a problem in a language that does not support OOP, they  
both do not understand the new paradigm well enough to structure their  
thinking appropriately for the language and they do not know the  
necessary idioms to effectively express chunks of computation.

All that said, you can build basic data hierarchies in your Mathematica  
programs quite easily if you encode the collection of data associated  
with an object as a list of rules and specialize function definitions  
("methods") using pattern matching. Here is a simple example:

obj={name->"instance of superclass",data->1};
printname[{___,name->name_,___}]:=Print[name]
printname[obj]
getdata[{___,data->data_,___}]:=data
getdata[obj]
subobj={name->"instance of subclass",data->2, subdata->{20,30}};
printname[subobj]
getdata[{___,data->data_,subdata->subdata_,___}]:={data,subdata}
getdata[subobj]
getdata[obj]

You can formalize this is various ways, by defining object constructors  
and so on. At the very least, you want to avoid typing these pattern  
matches all the time. Assigning the pattern to a variable essentially  
defines a class type:

class={___,name->name_,data->data_,___};
subclass=Join[class,{subdata->subdata_,___}];
mymethod[class,a_]:=a*data
mymethod[subclass,a_]:=a*data*{1,1}.subdata
mymethod[obj,2]
mymethod[subobj,2]

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.

Alex