Re: OOP in Mathematica
- To: mathgroup at smc.vnet.net
- Subject: [mg29206] Re: OOP in Mathematica
- From: "Orestis Vantzos" <atelesforos at hotmail.com>
- Date: Mon, 4 Jun 2001 05:30:40 -0400 (EDT)
- Organization: National Technical University of Athens, Greece
- References: <b3AP6.274$y25.1892@ralph.vnet.net> <9f2g4c$878$1@smc.vnet.net> <9f4euh$ab2$1@smc.vnet.net> <9f7j0e$grg$1@smc.vnet.net> <9fbndo$1bf$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
It all depends on what you consider an object, ofcourse. Is Pi an object? I think the answer in your case is yes. I on the other hand would consider it just a symbol (an important one with lots of properties, but a symbol nevertheless). To me, an object is "an autonomous, customizable and persistent piece of code, which communicates with the user with a rigorous set of methods". I think the concept in Mathematica which comes closest to this, is the concept of Contexts(or even Packages). It is an encapsulating device for symbols which offers the basic mechanisms for inheritance(another very important OOP concept). My aim is to fill the missing details. Orestis Vantzos- "OOP is in the eye of the beholder" "Drago Ganic" <drago.ganic at in2.hr> wrote in message news:9fbndo$1bf$1 at smc.vnet.net... > Orestis, > > I think that OO is conceptually wrong because in this philosophy functions are below objects ("everything is an object" and an object has attached functions to it ...) > > But these two elementary things are *on the same level*. An that's what is done in Mathematica when it is said that "everything is an expression". > > I do think that we can interpret the world as there are objects and functions and the wonderful thing symbolic programming has thought me is that they can be presented in a unified way: > > head [arg1, arg2, ... ] > > Often a thing is either an "object" or a "function": > > Complex [a, b] > vs. > Sin [Pi] > > but sometimes the distinction is not so clear as with > (when it don't gets numerically evaluated): > > Sin[1] > Sin[2] > ... > > So I think we should have a pool of "functions" like f, g ,... and a pool of "objects" like x, y, ... and we should combine them in something like f(x). In mathematics we will have situations like F(f) but usually we can distinguish between these two type of things. > > And that's it. And that's done in Mathematica except that overloading is not used as much as it should have so we have the commands NotebookCreate, NotebookDelete and so on. > > Just my opinion :-) > > Greetings from Croatia, > Drago Ganic > > > "Orestis Vantzos" <atelesforos at hotmail.com> wrote in message news:9f7j0e$grg$1 at smc.vnet.net... > > That's exactly why normal OOP philosophy can't work in Mathematica...methods > > and instance variables (in Maeder's terminology) can not be clearly > > distinguished. One would rather associate a number of symbols with an > > objects and allow the user to define their functionality. > > Orestis > > > > > > > > > > > > "John Doty" <jpd at w-d.org> wrote in message news:9f4euh$ab2$1 at smc.vnet.net... > > > In article <9f2g4c$878$1 at smc.vnet.net>, "Jens-Peer Kuska" > > > <kuska at informatik.uni-leipzig.de> wrote: > > > > > > > The head *is* the function call! > > > > > > No, the head is just the head. If a particular head is associated with > > > replacement rules that work like a function, you might want to call that > > > head a "function". On the other hand, you can invert function and argument > > > if you wish: > > > > > > In[33]:= x_[sin]^:=Sin[x] > > > > > > In[34]:= Pi[sin] > > > > > > Out[34]= 0 > > > > > > To be sure, most rules mimic function evaluation and/or sequential flow of > > > control. This makes Mathematica look more like a "normal" programming > > > language than it really is. It's really just a convention: Mathematica can > > > also define bizarre rules like the ones above. > > > > > > -- > > > | John Doty "You can't confuse me, that's my job." > > > | Home: jpd at w-d.org > > > | Work: jpd at space.mit.edu > > > > > > > > > > >