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