No registered users in community xowiki
in last 10 minutes
in last 10 minutes
[Xotcl] Re: [Xotcl] Re: [Xotcl] knowing who is called "next"
From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Mon, 22 Jan 2001 11:01:05 +0100
Gustaf Neumann wrote:
> >>>>> "CL" == Catherine Letondal <letondal_at_pasteur.fr> writes:
>
> CL> Hi,
>
> CL> Most of the time, I know what is going to be called when I peut a next
> CL> statement :
> CL> - the class instproc method if from a proc
> CL> - the mixin method if any
> CL> - the superclass method
> CL> etc..
>
> CL> My question is the following: I have sometimes the instproc
> CL> redefined at the instance level with a proc: this is to enable the
> CL> user to experiment a method on a given object without breaking all
> CL> the application (this is actually one the main reason for me to
> CL> use Xotcl). It's also a debug feature for more experimented
> CL> developpers.
>
> CL> However, I have the "next" problem in such case: it's the instproc
> CL> level which is called instead of either the mixin or superclass
> CL> method.
>
> Dear Catherine,
>
> why not letting the user to define mixin for the experimentation?
> you can still define other mixins/instmixins/etc. for your "own"
> purposes.
>
> what you seem to want is to change the onion shells of the next path
>
> filters mixins instmixins proc instprocs
>
> to something else, preferably starting with proc. note, that the
> onion shells are not atomic (with the exception of proc), but can
> be quite complicated (e.g. registering multiple cascaded filters),
> so simply "jumping" to a certain method of a certain Class won't let
> you to call there the "appropriate" method via next. changing or
> altering the order on the fly can lead to programs that are very hard
> to comprehend.
I don't really want to change this order - which indeed would make the program
much more complex to debug! I just want to be able to test whenever such
proc -> instproc behaviour happens and decide what to do about it - for instance
to have the instproc decide that the job is already done and to perform a next
for potential superclass calls.
I understand your suggestion of having user defining mixins. However
I think that the proc/instproc difference is much more simple to understand for
non-professional programmers.
During the discussions I have already had with biologists whom I have
shown my prototype, they understand this proc/instproc scheme at once.
Moreover, although I agree that mixin are a good tool to experiment - and intend to
explain this in a further step - mixins and proc do not really have the same
logical function and I prefer not to confuse them too much.
> We could implement a [[self] info next] or better a [self next] for
> introspection purposes (somewhat a generalization of "info
> calledproc"), but i am afraid, that this won't help you.
Oh yes, this would help a lot! :-)
Date: Mon, 22 Jan 2001 11:01:05 +0100
Gustaf Neumann wrote:
> >>>>> "CL" == Catherine Letondal <letondal_at_pasteur.fr> writes:
>
> CL> Hi,
>
> CL> Most of the time, I know what is going to be called when I peut a next
> CL> statement :
> CL> - the class instproc method if from a proc
> CL> - the mixin method if any
> CL> - the superclass method
> CL> etc..
>
> CL> My question is the following: I have sometimes the instproc
> CL> redefined at the instance level with a proc: this is to enable the
> CL> user to experiment a method on a given object without breaking all
> CL> the application (this is actually one the main reason for me to
> CL> use Xotcl). It's also a debug feature for more experimented
> CL> developpers.
>
> CL> However, I have the "next" problem in such case: it's the instproc
> CL> level which is called instead of either the mixin or superclass
> CL> method.
>
> Dear Catherine,
>
> why not letting the user to define mixin for the experimentation?
> you can still define other mixins/instmixins/etc. for your "own"
> purposes.
>
> what you seem to want is to change the onion shells of the next path
>
> filters mixins instmixins proc instprocs
>
> to something else, preferably starting with proc. note, that the
> onion shells are not atomic (with the exception of proc), but can
> be quite complicated (e.g. registering multiple cascaded filters),
> so simply "jumping" to a certain method of a certain Class won't let
> you to call there the "appropriate" method via next. changing or
> altering the order on the fly can lead to programs that are very hard
> to comprehend.
I don't really want to change this order - which indeed would make the program
much more complex to debug! I just want to be able to test whenever such
proc -> instproc behaviour happens and decide what to do about it - for instance
to have the instproc decide that the job is already done and to perform a next
for potential superclass calls.
I understand your suggestion of having user defining mixins. However
I think that the proc/instproc difference is much more simple to understand for
non-professional programmers.
During the discussions I have already had with biologists whom I have
shown my prototype, they understand this proc/instproc scheme at once.
Moreover, although I agree that mixin are a good tool to experiment - and intend to
explain this in a further step - mixins and proc do not really have the same
logical function and I prefer not to confuse them too much.
> We could implement a [[self] info next] or better a [self next] for
> introspection purposes (somewhat a generalization of "info
> calledproc"), but i am afraid, that this won't help you.
Oh yes, this would help a lot! :-)
-- Catherine Letondal -- Pasteur Institute Computing Center