Fwd: Re: [Xotcl] philosophical Q on slot approach

[Gustaf Neumann]

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

Subject: Re: [Xotcl] philosophical Q on slot approach
Date: Sun, 20 Jul 2003 02:41:04 +0200
From: Gustaf Neumann <neumann at wu-wien.ac.at>
To: Kristoffer Lawson <setok at 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 at 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

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

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