No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Fwd: Re: [Xotcl] philosophical Q on slot approach
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 20 Jul 2003 03:17:52 +0200
---------- 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
Date: Sun, 20 Jul 2003 03:17:52 +0200
---------- 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