Re: Re: OO in Mathematica
- To: mathgroup at smc.vnet.net
- Subject: [mg37664] Re: [mg37648] Re: OO in Mathematica
- From: Sseziwa Mukasa <mukasa at jeol.com>
- Date: Fri, 8 Nov 2002 02:14:01 -0500 (EST)
- Sender: owner-wri-mathgroup at wolfram.com
This is my last post on this thread I promise ;-) On Thursday, November 7, 2002, at 06:42 AM, Orestis Vantzos wrote: > Sseziwa Mukasa <mukasa at jeol.com> wrote in message > news:<aqb1dj$mih$1 at smc.vnet.net>... >> But what's wrong with defining fields as upvalues of a head indicating >> the record type? If you use the model demonstrated by Orestis >> (unfortunately due to the change in subject lines this thread seems to >> have split into 4 separate ones) you can inherit structure and methods >> etc. I know Orestis used downvalues but I think upvalues would be >> more >> efficient. I'd also change his method to use a symbol without a >> definition rather than overloading Dot. If you are using Mathematica >> you already have to condition yourself to use Map, Fold et al. rather >> than Do, For, While etc. What's wrong with using pattern matching for >> structures instead of tuples? > > The whole idea is going beyond a simple 'record', all the way to a > full fledged object, complete with methods. I used DownValues, because > I think that the message passing mechanism is best pictured in > Mathematica as obj@method[args] rather than as method[obj,args]. What > I mean to say is that the object obj receives the message method[args] > rather than method is applied on {obj,args}, which would be more > functional in style. > There is a major implementation issue related with my use of > DownValues, instead of UpValues. Although the identity of the object > is obvious, the identity of the method is not, given that inheritance > and polymorphism can identify several pieces of code with the same > 'method'. It is therefore wise to enclose the 'unstable' part of the > expression (method[args]) with the definite one (obj), incase some > form of processing is needed before the message is actualy evaluated > (in which case you would SetAttributes[onj,HoldAll] ). > The UpValues versus DownValues issue is a matter of taste as you seem to agree (as is the use of Dot). I was just suggesting the my personal preference is to use the UpValues. The post to which you are replying was a response to a question about porting code which used C struct types to Mathematica, OO issues were not mentioned. I was merely suggesting that if you wanted to mechanically port (by which I mean substituting a roughly equivalent Mathematica expression for each line of C code) C code containing structs then changing the structs to expressions with heads sorted by type may be a better idea than maintaining them as lists. That said, I have never had occasion to do this myself and am merely speculating about how I would approach such a project. From your posts it seems you have had experience in just such a project and I will defer to your wisdom on the subject. Finally to make my own position perfectly clear. I believe that Mathematica contains all that is necessary to program in an OO style but perhaps lacks tools to make such an endeavor easy. I'm not even sure what those tools should be since they would almost necessarily enforce some sort of OO policy decisions (ie. delegates as Orestis uses or the more static hierarchy using lists of rules presented earlier) which would make someone unhappy. In fact it seems that similarly to the way X Windows allows the creation of a GUI without specifying the rules of the GUI (focus follows mouse, menubar on window or desktop etc.) Mathematica allows OO without making decisions about the specific form either. To use OO in Mathematica then it would probably be better to understand the more general object model of a system such as CLOS than a more rigid model such as Java or C++. Anyway, I've already said more than I ever intended to on this subject. It seems the best way to make any productive contributions to this subject is for people to actually implement projects using OO techniques in Mathematica and present them. If there is any interest then I'm sure Mathematica users will be able to generalize whatever features are necessary to make OO programming easy in Mathematica and maybe even get them included as a standard package. Regards, Ssezi
- Follow-Ups:
- Re: Re: Re: OO in Mathematica
- From: "Hermann Schmitt" <schmitther@netcologne.de>
- Re: Re: Re: OO in Mathematica