---------- Forwarded Message ----------

Subject: Re: [Xotcl] philosophical Q on slot approach Date: Sun, 20 Jul 2003 02:41:04 +0200 From: Gustaf Neumann neumann@wu-wien.ac.at To: Kristoffer Lawson setok@fishpool.com

On Friday 18 July 2003 17:41, Kristoffer Lawson wrote:

I like the way XOTcl lacks the concept of private and public methods and I also thought that it is unnecessary for fields. I also very much like multiple inheritance as, while I don't use it very often, sometimes it is just quite the most natural way to go about business.

....

just for terminology issues: i think you are refering by "fields" to instance variables. let me re-iterate the basic "philosophical" point of view. Languages like xotcl are object-oriented, while languages like java (and most of UML) is class-oriented.

Class-oriented means: look at the class an you know exactly, how all of the instances look alike. The class is the first and primary language construct; the class is well the place where you specify the instance variables (there are no instance variables except those specified in the class). The only kind of individualism left in the objects is to let them differ by their state (the values of their instance variables). Changing classes (class migration) is conceptionally quite hard for this setup.

Object-oriented (in this distinction) means that the primary elements are objects, which keep all instance variables. classes my be used to specify the behavior of objects, they are container for methods and they control the life-cycle of objects. Objects are like the facts, and objects are like rules, that determine the behavior of the objects. Since the connection between objects and classes is rather loose, it is sufficient to define their relation through an association. Therefore it is quite easy to change the relation between objects and classes (and between classes and classes) dynamically. Objects have arbitrary individualism, they may have variables never used in any class, they may have private procs etc.

From the expressiveness, object-oriented languages can - in principle - be restricted to behave like class-oriented languages, but the other way around is much harder.

I do see the latter as much less of a problem but the first could be a real issue. It's probably just pure luck that I haven't had to debug it.

I have the same experience. Name clashes between instance variables within objects do happen only very seldomly. More often classes from MI or mixin classes want to collaborate and to share state by using the same instance variables.

I see two solutions to the problem:

1. A way to specify that you wish to modify or use a field and guarantee

that it is the one from "your own" class. Possibly the same for a method.

This is one of the reasons why there is a "instvar" method. A method specifies that it wants to modify a certain instance variable if it is only called by its variable name. It is quite easy to use traces to flag unwanted access (e.g. by using [self callingclass]).

If there have is a situation, where the unstructured instance variable namespace of an object is not sufficient, aggregation is the instrument of choice (e.g. a "Person" has many "Projects" aggregated).

2. Define that instance variables cannot be used from outside the class.

That they are always "private" and thus cannot conflict. This I sort of do anyway. I never access fields directly from outside the class.

look at the code of my posting about "static member functions" in http://alice.wu-wien.ac.at/pipermail/xotcl/2003-April/000383.html It is quite easy to change the policy form "callingobject" to "callingclass" or "callingproc" to to a combination of these. This way you can detect "abuses" of certain variables.

Another goal might be to avoid name clashes (e.g. the instance variable name of method m1 should be a different variable than the instance variable name of method m2). This way the names cannot clash, but the state cannot be shared. Approaches to avoid clashes are aggragations or to use an indirection layer for accessing instance variables. You can define a method "getinstvar context name" that might allocate and return the variable name (something like __instvar223-mycontext). This method could be used like in set name [getinstvar [self proc]-[self class] name] my set $name "K. Lawson"

i am still not sure whether i understood your question correctly.

Maybe a combination of the two. In Java, or any language with only single inheritance, this is not an issue (and thus private-protected-public is mostly unnecessary).

Opinions? (wondering if I'm still on the list as I haven't seen any emails from there in ages)

Check out http://alice.wu-wien.ac.at/pipermail/xotcl/ whether you have missed something.

all the best -gustaf

                          / http://www.fishpool.com/~setok/

---

Xotcl mailing list - Xotcl@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

-- Univ.Prof. Dr.Gustaf Neumann Abteilung für Wirtschaftsinformatik WU-Wien, Augasse 2-6, 1090 Wien

-------------------------------------------------------