While working on the multithreaded related parts it has become clear that the term "scope" is very
important, such that I linked the word "scope" to the respective section that describes it.
Also, looking at questions and answers in the RexxLA mailing list related to multithreading "scope"
turns out to not be well understood, if at all. With the interlinking and additional explanations
this may have been improved a little bit.
However, there is one omission IMHO for ooRexx. ooRexx being a dynamic language should allow for
introspection/reflection (which it does in many different aspects) of the current scope, such that
one can learn within a method to which scope it belongs to, got defined for. It would help the
ooRexx programmer to experiment with and to determine the scope of a method at runtime.
To the best of my knowledge it is not possible to get at the method's scope at
runtime.
Currently, within a method we can get at the object that invoked it (self) and its immediate
superclass (super), but not at the scope (class object) that the method belongs to. As a method may
be used in different scopes depending on the context, maybe RexxContext would be a class where a new
method "scope" could be added to return the "scope": for routines it would return .nil, for methods
the class object that defines the scope of the method, and .nil for floating methods. So the idea
would be that ".context~scope" would return it.
Would that be a sensible solution or are there better possibilities?
Maybe adding an entry "SCOPE" to the TraceObject instance and supplying the value that gets used for
the ">I>" trace line?
What do you think?
---rony
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
