On Mon, May 16, 2022 at 2:35 PM Rony G. Flatscher <rony.flatsc...@wu.ac.at> wrote:
> Commits: > > - <http://sourceforge.net/p/oorexx/code-0/12391> > <http://sourceforge.net/p/oorexx/code-0/12391>, > - <http://sourceforge.net/p/oorexx/code-0/12392> > <http://sourceforge.net/p/oorexx/code-0/12392>. > > Also removed "Error_Execution_super" definitions from various *.h files > manually as not having been able to get cmake to find xalan to recreate the > files from <main/trunk/interpreter/messages/rexxmsg.xml>. > You really shouldn't have done that. In the past, we have left obsoleted error messages in place because users can actually use those messages with the RAISE instruction. Granted it's a small risk that that particular message has been used, but it is part of the whole programming infrastructure. > > Two questions: > > - on Windows (having the Java version of Xalan): where to get Xalan > from, or alternatively, how to get cmake to find and use the Java Xalan > version? > - ad documentation w.r.t Error_Execution_super: have not found the > relevant section in rexxref.pdf, unfortunately. Maybe others can find that > and point it out, or maybe even adjust the text ;) ? > > section 4.2.7 of the reference. > > > ---rony > > > On 16.05.2022 14:55, Rony G. Flatscher wrote: > > On 16.05.2022 14:33, Rick McGuire wrote: > > 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. > > Thank you for your hints and pointers, will take care of it. > > ---rony > > > 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
