On Tue, May 17, 2022 at 1:09 PM Rony G. Flatscher <rony.flatsc...@wu.ac.at>
wrote:
> Did not find a testgroup for the forward keyword statement.
>
> Adding the following tests to Message.testGroup:
>
It would be better to create a new testGroup for the forward keyword. This
is all about how the instruction handles this and not necessarily the
underlying mechanism. Obviously someone should take a look at making a more
complete set of tests, but that's an exercise for another day.
> -- FORWARD: tests with mixinclasses
> ::method test_forward_mixinclasses_01
> o=.mixin2~new
> self~assertEquals("mixin2" , o~info )
> self~assertEquals("mixin2" , o~testForwardSuper_to_info )
> self~assertEquals("base" , o~testForwardSuper_Base )
> self~assertEquals("mixin1a" , o~testForwardSuper_Mixin1a )
> self~assertEquals("mixin1b" , o~testForwardSuper_Mixin1b )
> self~assertEquals("mixin2" , o~testForwardSuper_Mixin2 )
>
> -- self~expectSyntax(93.957) -- should be: 93.957 "Target object "a
> MIXIN2" is not a subclass of the message override scope (The NIXINOXI class)."
> self~expectSyntax(97.1) -- Object cannot understand message
> self~assertEquals("nixinoxi", o~testForwardSuper_NixiNoxi)
>
>
> ::class nixinoxi -- has info method, but class is on its own
> ::method info
> return "nixinoxi"
>
> ::class base
> ::method info
> return "base"
>
> ::method testForwardSuper_to_info
> forward message "info"
>
> ::method testForwardSuper_Base
> -- forward message (("info",.base)) -- does not work
>
> And it shouldn't.
> forward class (.base) message "info"
>
> ::method testForwardSuper_Mixin1a
> forward class (.mixin1a) message "info"
>
> ::method testForwardSuper_Mixin1b
> forward class (.mixin1b) message "info"
>
> ::method testForwardSuper_Mixin2
> forward class (.mixin2) message "info"
>
> ::method testForwardSuper_NixiNoxi
> forward class (.nixinoxi) message "info"
>
>
> ::class mixin1a mixinclass base
> ::method info
> return "mixin1a"
>
> ::class mixin1b mixinclass base
> ::method info
> return "mixin1b"
>
> ::class mixin2 mixinclass mixin1b inherit mixin1a
> ::method info
> return "mixin2"
>
>
> So the message expression must yield a plain message name (returning an
> array not allowed). The question is, whether this is o.k. or not. As there
> is the CLASS option one can supply the desired scope right there, so no
> need to put it into the MESSAGE option at all.
>
That is correct.
> The error message 93.957 ("Target object "a MIXIN2" is not a subclass of
> the message override scope (The NIXINOXI class).") is not raised, rather
> 97.1. This may be something to tackle, such that the same error messages
> get raised as with message instructions, .message, and .object.
>
Yes, now that the can of worms has been opened, it should be made
consistent.
> (Need to leave.)
>
> ---rony
>
>
> On 17.05.2022 16:49, Rony G. Flatscher wrote:
>
> On 17.05.2022 16:29, Rick McGuire wrote:
>
> If you're playing around with this, also check the FORWARD instruction
> tests to see if they need adjustment. If there's not good coverage for
> these situation, then additional tests should be added.
>
> Also, there need to be tests for the FORWARD instruction where it is used
> to pass the method invocation to a different object with a superclass
> override to make sure that works.
>
> Will do (would not be able to do them today, urgent need to do work
> related stuff).
>
> ---rony
>
>
>
> On Tue, May 17, 2022 at 10:10 AM Rony G. Flatscher <
> rony.flatsc...@wu.ac.at> wrote:
>
>> So this is the patch I intend to apply such that message instructions
>> report exactly the same errors as .Message and .Object:
>>
>> Index: interpreter/expression/ExpressionMessage.cpp
>> ===================================================================
>> --- interpreter/expression/ExpressionMessage.cpp (revision 12394)
>> +++ interpreter/expression/ExpressionMessage.cpp (working copy)
>> @@ -162,6 +162,13 @@
>> if (super != OREF_NULL)
>> {
>> _super = (RexxClass *)super->evaluate(context, stack);
>> + // _super an instance of TheClassClass
>> + if (!_super->isInstanceOf(TheClassClass))
>> + {
>> + reportException(Error_Invalid_argument_noclass, "SCOPE",
>> "Class");
>> + }
>> + // validate the starting scope
>> + _target->validateScopeOverride(_super);
>> // we send the message using the stack, which
>> // expects to find the target and the arguments
>> // on the stack, but not the super. We need to
>> Index: interpreter/instructions/MessageInstruction.cpp
>> ===================================================================
>> --- interpreter/instructions/MessageInstruction.cpp (revision 12394)
>> +++ interpreter/instructions/MessageInstruction.cpp (working copy)
>> @@ -161,6 +161,13 @@
>> {
>> // get the superclass target
>> _super = (RexxClass *)super->evaluate(context, stack);
>> + // _super an instance of TheClassClass
>> + if (!_super->isInstanceOf(TheClassClass))
>> + {
>> + reportException(Error_Invalid_argument_noclass, "SCOPE",
>> "Class");
>> + }
>> + // validate the starting scope
>> + _target->validateScopeOverride(_super);
>> // we send the message using the stack, which
>> // expects to find the target and the arguments
>> // on the stack, but not the super. We need to
>>
>> ---rony
>>
>>
>> On 17.05.2022 15:46, Rony G. Flatscher wrote:
>>
>> Forgot to add tests for the message instructions so went back to the
>> testgroup to add them and found out, that the tests for illegal overrides
>> returned 97.1 and not what .Message and .Object raise, namely 93.957
>> (receiver class not a subclass of override object) and 88.914 (SCOPE must
>> be instance of class Class).
>>
>> Instead of having 97.1 (object method not found), which does not point at
>> the reason I would like a message instructions to report an error with the
>> override explicitly. Of course, the tests depend on whether 97.1 or 93.957
>> gets reported.
>>
>> To do so I intend to add this:
>>
>> Index: interpreter/expression/ExpressionMessage.cpp
>> ===================================================================
>> --- interpreter/expression/ExpressionMessage.cpp (revision 12394)
>> +++ interpreter/expression/ExpressionMessage.cpp (working copy)
>> @@ -162,6 +162,8 @@
>> if (super != OREF_NULL)
>> {
>> _super = (RexxClass *)super->evaluate(context, stack);
>> + // validate the starting scope
>> + _target->validateScopeOverride(_super);
>> // we send the message using the stack, which
>> // expects to find the target and the arguments
>> // on the stack, but not the super. We need to
>> Index: interpreter/instructions/MessageInstruction.cpp
>> ===================================================================
>> --- interpreter/instructions/MessageInstruction.cpp (revision 12394)
>> +++ interpreter/instructions/MessageInstruction.cpp (working copy)
>> @@ -161,6 +161,8 @@
>> {
>> // get the superclass target
>> _super = (RexxClass *)super->evaluate(context, stack);
>> + // validate the starting scope
>> + _target->validateScopeOverride(_super);
>> // we send the message using the stack, which
>> // expects to find the target and the arguments
>> // on the stack, but not the super. We need to
>>
>> Maybe a test whether _super is an instance of class Class should be
>> carried out first to become able to also raise 88.914? If so, what would be
>> the easiest way to do so?
>>
>> Am I missing something else? Are there any objections?
>>
>> ---rony
>>
>>
>> On 17.05.2022 14:03, Rick McGuire wrote:
>>
>> I repeat, these are not acceptable tests. Please make the appropriate
>> corrections to them. Turn these into actual functional tests, otherwise
>> they have no real purpose.
>>
>> Rick
>>
>> On Tue, May 17, 2022 at 8:01 AM Rony G. Flatscher <
>> rony.flatsc...@wu.ac.at> wrote:
>>
>>> On 17.05.2022 13:37, Rick McGuire wrote:
>>>
>>> This is not an acceptable way to fix these tests. Just removing the
>>> expected error and adding a totally unnecessary tautological assertion is
>>> not enough. These tests need to also verify that the correct method has
>>> been invoked by checking the return value from the method call.
>>>
>>> Two remarks:
>>>
>>> - There were existing tests that expected an error, if the override
>>> was not done to a message to self. These tests would now fail as these
>>> overrides are allowed. So removing the expected error turns the test into
>>> the opposite, testing whether an override is accepted and carried out. If
>>> the override takes place successfully assertTrue(.true) is used to
>>> increase
>>> the success assertion counter, otherwise the test suite would not be able
>>> to increase that counter anymore.
>>>
>>> - Ad testing whether the overrides work correctly, i.e. invoking the
>>> expected methods, these tests are the ones that I added explicitly, such
>>> that this aspect gets tested as well for send, sendWith, start, startWith
>>> for both, the .Message and the .Object classes. If you look up these test
>>> groups you will see that the tests include override tests for
>>> mixinclasses
>>> where the results of the invoked messages get tested for correctness. It
>>> may be the case that I am missing some tests, if so, please advise.
>>>
>>> ---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
