Xref: utzoo comp.object:3358 comp.lang.eiffel:1539 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!samsung!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.object,comp.lang.eiffel Subject: Re: Unification: Class=Type=Module Message-ID: <1991Apr25.214017.11189@Think.COM> Date: 25 Apr 91 21:40:17 GMT References: <1991Apr23.142800.12215@bony1.bony.com> <1991Apr25.074758.6153@jyu.fi> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 30 In article <1991Apr25.074758.6153@jyu.fi> sakkinen@jytko.jyu.fi (Markku Sakkinen) writes: >I have not read about any object-oriented language that would allow >several owners in an operation (unless the specification language >DisCo is counted). In the generic functions (multi-methods) >of CLOS, the _selection_ of actual method(s) to be invoked can be based >on more than one argument, but in the _execution_ there is only >one "self". This is incorrect, CLOS has no inherent notion of "self", neither at method selection time nor during the execution of the methods. All the parameters are accessed by name. WITH-SLOTS and WITH-ACCESSORS can be used to make the slots of instances accessible as if they were variables, but this is not done automatically, and can be done for more than one argument, or even for something that isn't an argument (CLOS provides no information hiding or visibility control -- everything is public, and programmers are expected to use other mechanisms, such as packages to implement visibility control). In generic functions where there's only one argument that is used to control method selection, some people have a convention of calling the argument SELF in the method definitions (in generic function definitions it's preferable to use a more descriptive name). There's nothing special about this name, though; most OO programmers were trained using languages that did have a distinguished "self", and have gotten used to thinking that way. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar