No registered users in community xowiki
in last 10 minutes
in last 10 minutes
[Xotcl] philosophical Q on slot approach
From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Fri, 18 Jul 2003 18:41:46 +0300 (EEST)
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/
Date: Fri, 18 Jul 2003 18:41:46 +0300 (EEST)
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/