Commits:
* <http://sourceforge.net/p/oorexx/code-0/12391>,
* <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>.
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 ;) ?
---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
