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