Xotcl July 2003

xotcl@alice.wu.ac.at

2 participants
2 discussions

Fwd: Re: [Xotcl] philosophical Q on slot approach
by Gustaf Neumann 20 Jul '03

20 Jul '03

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

1 0

philosophical Q on slot approach
by Kristoffer Lawson 18 Jul '03

18 Jul '03

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. However isn't there actually a problem here, especially in relation to fields and MI? I don't consider fields to be equally a part of the interface as I do methods so there is a grave risk that, unknowingly, field names from different paths could conflict thus leading to very unexpected behaviour of the kind that is also difficult to track and debug. While commonly I accept the "allow the coder to do anything" idea, which is prominent in Tcl this really would happen for no fault of the developer. They are combining classes in a way which is natural and generally do not expect side-effects to occur as a result. To a lesser extent one could consider this to be a problem with methods too. Methods I do consider to be part of the interface and are more easier to track -- thus the mixing behaviour is easier to understand. Still, there is the possibility that a method of a class would like to call another method (a helper method, perhaps) and be sure it's not getting muddled by another class. 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 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. 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. 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) / http://www.fishpool.com/~setok/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

Xotcl July 2003