You have only fixed part of the problem. There's also a change required to
MessageInstruction.cpp and also tests needed for that case.
Rick
On Mon, May 16, 2022 at 8:15 AM Rick McGuire <object.r...@gmail.com> wrote:
> Weren't there any tests for the restriction that needed to be removed? I
> only need new tests added for the case where this is not restricted. Also,
> I'd recommend adding some tests using mixins to make sure the correct
> targets are getting invoked.
>
> Rick
>
> On Mon, May 16, 2022 at 8:10 AM Rony G. Flatscher <rony.flatsc...@wu.ac.at>
> wrote:
>
>>
>> On 15.05.2022 14:47, Rony G. Flatscher wrote:
>>
>>
>> On 15.05.2022 12:27, Rony G. Flatscher wrote:
>>
>> 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
>>
>> Opened a RFE for this:
>> <https://sourceforge.net/p/oorexx/feature-requests/802/>
>> <https://sourceforge.net/p/oorexx/feature-requests/802/>
>>
>> ---rony
>>
>> Implemented <http://sourceforge.net/p/oorexx/code-0/12390>
>> <http://sourceforge.net/p/oorexx/code-0/12390>. Added appropriate tests.
>>
>> ---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
