On 27.03.2024 14:26, Rick McGuire wrote:
I also want to point out this was something I pointed out previously when I said that the lock
count was not a very useful piece of information in the original trace proposal. What is really
needed is the combination of "object instance (perhaps the identity hash)" + "method scope (to
identify the variable pool in question)" + "the lock count for the activity".
That will uniquely identify what the scope lock situation is.
How about an entry OBJECTID with the identity hash as a value?
---rony
On Wed, Mar 27, 2024 at 9:10 AM Rony G. Flatscher <rony.flatsc...@wu.ac.at>
wrote:
Consider the following short program that defines a class and an instance
method and uses them:
.TraceObject~option='N'
.test~clzHi -- class method will be invoked
.test~new~hi -- instance method will be invoked
::class test
::method clzHi class
say self": clzHi, scope:" .context~executable~scope
::method hi
say self": Hi, scope:" .context~executable~scope
::options trace all
Running it yields the following output:
1 *-* .TraceObject~option='N'
2 *-* .test~clzHi -- class method will be invoked
*>I> Method "CLZHI" with scope "TEST" in package
"G:\test\orx\trace\examples4docs\hmm\test_scope.rex".*
7 *-* say self": clzHi, scope:" .context~executable~scope
The TEST class: clzHi, scope: The TEST class
3 *-* .test~new~hi -- instance method will be invoked
*>I> Method "HI" with scope "TEST" in package
"G:\test\orx\trace\examples4docs\hmm\test_scope.rex".*
9 *-* say self": Hi, scope:" .context~executable~scope
a TEST: Hi, scope: The TEST class
The ">I>" trace line hints that both methods share the same scope "TEST"
which is not the case
as the class method and the instance method should have different scopes,
which is also
indicated by the following variant (full debug information):
.TraceObject~option='*F*'
.test~clzHi -- class method will be invoked
.test~new~hi -- instance method will be invoked
::class test
::method clzHi class
say self": clzHi, scope:" .context~executable~scope
::method hi
say self": Hi, scope:" .context~executable~scope
::options trace all
which yields the following output:
1 *-* .TraceObject~option='F'
[R1 T1 I1 ] 2 *-* .test~clzHi -- class
method will be invoked
[R1 T1 I2 G*A1* L0 ]*>I> Method "CLZHI" with scope "TEST"
in package
"G:\test\orx\trace\examples4docs\hmm\test_scope.rex".*
[R1 T1 I2 G*A1* L1 *] 7 *-* say self": clzHi, scope:"
.context~executable~scope
The TEST class: clzHi, scope: The TEST class
[R1 T1 I1 ] 3 *-* .test~new~hi -- instance
method will be invoked
[R1 T1 I3 G*A2* L0 ]*>I> Method "HI" with scope "TEST" in
package
"G:\test\orx\trace\examples4docs\hmm\test_scope.rex".*
[R1 T1 I3 G*A2* L1 *] 9 *-* say self": Hi, scope:"
.context~executable~scope
a TEST: Hi, scope: The TEST class
As can be seen the attribute (object variable) pool is different as the
scope is really
different ("A1" versus "A2").
Method's scope() method returns the same class object. The TRACE ">I>"
output also does not
allow for differentiating between the two scopes.
Maybe the ">I>" output could add something like '... scope "TEST" /at the
class level /...' in
the case of a class method?
Also, it would be helpful to learn whether from a method object (if
.context~executable~isA(.method) then...) whether its scope is at the class
level (the method
is a class method) or at the instance level. Maybe some method
isClassMethod or so?
Would that be a feasible extension?
---rony
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
