Hi Jeremy,
a few minutes ago I committed Jean Louis' patch #5 ("retro-trace") to trunk such that the next
ooRexx installation and portable packages will include RFE 835 for testing such that you can get
your hands on it.
The test script I used to test it:
.context~package~local~traceOption="A"
call he
call ho
say
t=.test~new
t~~he~~ho~~ha~~hi
::routine he
say .context~name", line #" .line
say
::routine ho
trace (.traceOption) -- trace l
say .context~name", line #" .line "(trace l)"
say
::class test
::method he
say .context~name", line #" .line
say
::method ho
trace (.traceOption) -- trace l
say .context~name", line #" .line "(trace l)"
say
::method ha
expose abc
say .context~name", line #" .line
say
::method hi
expose abc
trace (.traceOption) -- trace l
say .context~name", line #" .line "(trace l after expose)"
say
ooRexx being a dynamic and a very versatile language allows for many variations. In this case the
package's (= program's) local directory gets the trace option assigned with the index name
traceOption such that using the environment symbol .traceOption will retrieve that value which then
gets used to define the trace type. Just changing "A" at the top to "N" would turn off tracing.
Such a solution would allow one to pick the routines and methods individually that get traced and
the trace option to use can be defined centrally, in this case only affecting the routines and
methods of the little test program.
---
The location to download the new version [r12839] for testing is eventually at
<https://sourceforge.net/projects/oorexx/files/oorexx/5.1.0beta/>.
HTH,
---rony
On 30.05.2024 10:58, Jeremy Nicoll wrote:
IIUC the idea is that a "trace" statement that turns on label-tracing
could be the first executable instruction in a method/routine, & could
generate that routine's invocation trace (even though strictly speaking
the invocation has already happened).
If the method/routine doesn't use "expose" then we might have eg
::method ...
if something_or_other then trace i
and if it does use expose then eg:
::method ...
expose this that other
if something_or_other then trace i
Jean Louis Faucher suggested that, to allow a passed parameter to turn
on such tracing one could use something like
::method ...
trace value (arg(3) == .true)~?("i", "o”)
use strict arg arg1, arg2, trace=.false
...
or:
::method ...
expose this that other
trace value (arg(3) == .true)~?("i", "o”)
use strict arg arg1, arg2, trace=.false
...
Somthing like that seems to me to be "un-REXX-ish" - far from intuitive,
and also quite likely accidentally not to be updated if/when someone
changes the way parameters are passed & suddenly it's no longer arg 3
that is significant.
It's a pity to have a named argument in the "use" statement and then
not be able to use that name, to get the invocation trace to occur.
Also, would a "trace o" turn off whatever package-wide tracing options
the user might have set up (& want) via "::options trace"?
Would it be so terrible not to have this convoluted approach and simply
have the logic that responds to "trace i" etc test whether invocation
was already traced, and if not, generate a line like
" >I> Method .myClass~myMethod (implied)"
OK, it wouldn't be in /precisely/ the right place in the trace output,
but since probably most people would still have their trace logic very
close to the start of a method/routine, it wouldn't be far off.
Documentation could explain why this was an /implied/ invocation.
And then people COULD refer to their named arguments. So eg
::method ...
use strict arg arg1, arg2, traceint=.false, tracecmd=.false
if traceint then trace i
if tracecmd then trace c
...
or:
::method ...
expose this that other
use strict arg arg1, arg2, traceint=.false, tracecmd=.false
if traceint then trace i
if tracecmd then trace c
...
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
