On 14.05.2022 22:06, Jean Louis Faucher wrote:
* So there is a need for having one or more methods that can be used for
forcing the invocation
of the ooRexx .Object methods.
The syntax described in 4.2.7 Changing the Search Order for Methods could be
used, if the restriction
"Message search overrides can be used only from methods of the target object”
was removed.
It works with oorexx4, after removing the check
if (_target != context->getReceiver())
in RexxExpressionMessage::evaluate.
s1 = "hello"
s2 = "hello"
say s1~"="(s2) -- display 1
say s1~"=":.Object(s2) -- display 0 because not the same objects
Indeed that would really be a general, fine solution alleviating a programmer to come up with weird
and cumbersome solutions.
Rather than having to create methods SEND.SUPER, SENDWITH.SUPER, CLASS.SUPER and COPY.SUPER to allow
programmers to invoke the ooRexx root class methods in .object, this problem with OLEObject, but
also all comparable in general would be solved with this. So instead one could code
* ole~send(msg) ... will check for existence on the Windows side, and if
present invoke it,
otherwise lookup super (which is .object)
* ole~send:.object(msg) ... will start resolving the method in the superclass
bypassing inspecting
.oleobject
and with the same technique:
* ole~sendWith:.object(msg,arrArg)
* ole~copy:.object
* ole~class:.object
This would be much easier and very clear.
In ooRexx 5.0 this would be the place to change:
Index: interpreter/expression/ExpressionMessage.cpp
===================================================================
--- interpreter/expression/ExpressionMessage.cpp (revision 12388)
+++ interpreter/expression/ExpressionMessage.cpp (working copy)
@@ -161,6 +161,7 @@
// do we have a super class override?
if (super != OREF_NULL)
{
+/*
// super class overrides are only allowed if the
// sender and the target are the same object (i.e., a message to
SELF)
if (_target != context->getReceiver())
@@ -167,6 +168,7 @@
{
reportException(Error_Execution_super);
}
+*/
_super = (RexxClass *)super->evaluate(context, stack);
// we send the message using the stack, which
Doing so will make your example work on ooRexx 5 as well!
Also experimented with other scenarious, including ones where "mistakingly" wrong override classes
get supplied.
arr=.array~of("a", "b")
........................................... rexxtry.rex on WindowsNT
say arr~items
2
........................................... rexxtry.rex on WindowsNT
say arr~items:super
Oooops ! ... try again. Object method not found.
Object "an Array" does not understand message
"ITEMS".
rc = 97.1 ................................. rexxtry.rex on WindowsNT
say arr~items:.collection
2
........................................... rexxtry.rex on WindowsNT
say arr~items:.rexxinfo
Oooops ! ... try again. Object method not found.
Object "an Array" does not understand message
"ITEMS".
rc = 97.1 ................................. rexxtry.rex on WindowsNT
say arr~copy
a
b
........................................... rexxtry.rex on WindowsNT
say arr~copy:.rexxinfo
Oooops ! ... try again. Object method not found.
Object "an Array" does not understand message
"COPY".
rc = 97.1 ................................. rexxtry.rex on WindowsNT
say arr~copy:.object
a
b
........................................... rexxtry.rex on WindowsNT
So ooRexx 5 already catches wrong overrides and raises the appropriate conditions (cf. overrides
"super", ".rexxinfo" above)!
---
Conceptually this change will allow the programmer to not only send a message to the object, but
also to tell the object in which superclass to start the search for a matching method if he has a
need to do so.
In the case of .OLEObject it makes it simple for programmers to tell the OLE object to start its
search for a method in the root class .object applying existing knowledge! So no need to come up
with awkwardly named methods or another dispatch.super method to somehow get access to the root
class methods making the usage/protocol of such classes rather complicated. So such a change would
simply allow to apply the message resolution override pattern that the programmer is accustomed to
already.
---
The question would be whether there are any potentially dangerous side-effects or incompatibilies
with existing code that could get introduced by removing this particular check.
---rony
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
