[Xotcl] Re: [Xotcl] Re: [Xotcl] knowing who is called "next"

[Catherine Letondal]

Gustaf Neumann wrote:
> >>>>> "CL" == Catherine Letondal <letondal@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