Hi,
Most of the time, I know what is going to be called when I peut a next statement : - the class instproc method if from a proc - the mixin method if any - the superclass method etc..
My question is the following: I have sometimes the instproc redefined at the instance level with a proc: this is to enable the user to experiment a method on a given object without breaking all the application (this is actually one the main reason for me to use Xotcl). It's also a debug feature for more experimented developpers.
However, I have the "next" problem in such case: it's the instproc level which is called instead of either the mixin or superclass method.
Is there any way either: - to ask by introspection who is going to be called - e.g something like: [[self] info next methodname] - to enforce it: classname next
I know the procsearch command, but it doesn't take a "next" argument!? I have tried : puts "procsearch: [[self] procsearch next]" which gives this output: procsearch: ::buttondata0::next (buttondata0 is an instance for which a proc has been defined) ::buttondata0 proc
I don't see any solutions with 'info called/calling' features either?
Many thanks!
"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.
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.
best regards -gustaf
CL> Is there any way either: CL> - to ask by introspection who is going to be called - CL> e.g something like: CL> [[self] info next methodname] CL> - to enforce it: CL> classname next
CL> I know the procsearch command, but it doesn't take a "next" CL> argument!? I have tried : CL> puts "procsearch: [[self] procsearch next]" CL> which gives this output: CL> procsearch: ::buttondata0::next CL> (buttondata0 is an instance for which a proc has been defined) CL> ::buttondata0 proc
CL> I don't see any solutions with 'info called/calling' features either?
CL> Many thanks!
CL> -- CL> Catherine Letondal -- Pasteur Institute Computing Center
CL> _______________________________________________ CL> Xotcl mailing list - Xotcl@wi.wu-wien.ac.at CL> http://wi.wu-wien.ac.at/mailman/listinfo/xotcl
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 instprocsto 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
-
Catherine Letondal -
Gustaf Neumann