There are also other places where this check is made. Search for
Error_Execution_super to find it. The entire validateOverrideContext()
method and it's calls should be deleted.
Rick
On Mon, May 16, 2022 at 8:24 AM Rick McGuire <object.r...@gmail.com> wrote:
> 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
