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.
Rick
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
>
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
