bugGNU Octave - Bugs: bug #42735, subclass inheritence: symbol ops...


bug #42735: subclass inheritence: symbol ops (e.g., plus, mtimes) do not respect superiorto

Submitted by:  Colin Macdonald <cbm>
Submitted on:  Fri 11 Jul 2014 11:08:52 PM UTC  
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  Any

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Sun 23 Apr 2017 10:47:06 PM UTC, comment #12:

In Colin's original example of two old-style classes that are not related by inheritance, the only thing that needs to be implemented is calling the correct operator method. I already pointed to the relevant lines of code in comment #3, this is still valid and I believe the correct place to solve this.

I haven't looked at all into how much work is needed on the classdef side, but the parser work seems to have been done a long time ago, the properties are already parsed and stored in the metaclass, that information just needs to be used elsewhere, probably passed on to the symbol table the way it is done currently in the inferiorto and superiorto functions.

Mike Miller <mtmiller>
Project Administrator
Sun 23 Apr 2017 10:33:32 PM UTC, comment #11:

The parser is already handling and storing all of the information from calls to inferiorto, superiorto, and the classdef InferiorClasses property. These bits just need to be used when determining how to dispatch function and method calls.

Look at the metaclass to verify that all of the class properties have been parsed correctly

I would first test all of the examples posted on this bug report from 2014 on the current default branch, because several changes have been made to how method dispatch and overloading is implemented. Then decide what is working and what still needs to be completed, both for old classes and classdef classes.

Mike Miller <mtmiller>
Project Administrator
Fri 24 Mar 2017 07:21:04 PM UTC, comment #10:

Hi, can anyone familiar with the parser please let me know where to begin to solve this. I still can't find where to look. if a class is defined as "classdef (InferiorClasses = {?A}) D < A" how do I make sure to read this info in the definition of class D? For normal classes, 'superiorto' works where the class is provided as argument. But for classdef we need this syntax and I have no clue how to parse this.

Abhinav Tripathi <genuinelucifer>
Sat 04 Feb 2017 07:36:50 AM UTC, comment #9:

I don't know the answer to your question. But does it help that old-style classes also exhibit this bug? Does Octave do anything (parsing for example) with "superiorto"?

Colin Macdonald <cbm>
Sat 04 Feb 2017 07:12:26 AM UTC, comment #8:

I was trying to work on this issue but am totally lost on how to implement the 'InferiorClasses' thing. How to process something like 'classdef (InferiorClasses = {?A}) D < A' to get all the inferior classes in c++ code? Is this information currently stored anywhere? I couldn't find anything that would help me to add a new parsing logic to parse such phrases.

Abhinav Tripathi <genuinelucifer>
Thu 19 Jan 2017 05:17:32 AM UTC, comment #7:

Note, that Mike already said all this below, but now I understand it ;-) Maybe my A,B,C,D classes can be worked into a test case.

Colin Macdonald <cbm>
Thu 19 Jan 2017 05:15:44 AM UTC, comment #6:

Aha, yes "InteriorClasses" is key. Now D is defined as "classdef (InferiorClasses = {?A}) D < A"



(file #39509)

Colin Macdonald <cbm>
Thu 19 Jan 2017 05:10:38 AM UTC, comment #5:

Ok, I've done some tests with three classdef classes: A and B are unrelated. C is a subclass of A. Attached below.

Here is what Matlab 2015b does:

Note "a + c" calls the A@plus! That was unexpected: I suppose that is what "InferiorClasses" is all about. Will check that next..., stay tuned.

So far, the results from Octave are the same:

(file #39506, file #39507, file #39508)

Colin Macdonald <cbm>
Tue 01 Nov 2016 05:42:47 AM UTC, comment #4:

This page (https://www.mathworks.com/help/matlab/matlab_oop/object-precedence-in-expressions-using-operators.html) suggests that if two user-defined classes are completely unrelated, the left-hand object's method is used (which is what Octave implements today).

So the logic that is lacking here is relationships between class inheritance (both old and new style OO), old-style superiorto/inferiorto relationships, and new-style InferiorClasses relationships.

Mike Miller <mtmiller>
Project Administrator
Tue 01 Nov 2016 05:29:17 AM UTC, comment #3:

The cause of this behavior is right here


When a binary operator is called with one or two class arguments, the class type of the left hand argument takes precedence. There should be additional checking if they are both class types.

Can you test what Matlab does in this case if the two classes are completely unrelated (no inheritance, no superiorto declaration, just two classes that both provide plus methods)?

Mike Miller <mtmiller>
Project Administrator
Fri 11 Jul 2014 11:30:50 PM UTC, comment #2:

Unsurprisingly, "<double> + C" seems to work. Its just P + C that does the wrong thing.

Colin Macdonald <cbm>
Fri 11 Jul 2014 11:09:38 PM UTC, comment #1:

also present in 3.6.4.

Colin Macdonald <cbm>
Fri 11 Jul 2014 11:08:52 PM UTC, original submission:

I have a class called parent and a class called child.

Say P is instance of parent and C is instance of child.

parent and child have "myplus" and "plus" methods.

1) P+C and C+P call different plus methods, independent of whether superiotor('parent') is set. This behaviour DOES NOT match matlab.

2) plus(P,C) and plus(C,P) call the child plus method if superiorto is set, otherwise different methods. This behaviour matches matlab 2008a.

3) myplus(P,C) and myplus(C,P) call the child myplus method if superiorto is set, otherwise different methods. This behaviour matches matlab 2008a.

Tested with plus, minus, mtimes. Tested on 3.8.1 and "hg - 1 month".

(personally, I don't see why I'd ever want the behaviour w/o superiorto, but that is not the bug here)

I'll attach my minimal example: untar and run mytest.m

Colin Macdonald <cbm>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #39509:  D.m added by cbm (207B - application/vnd.wolfram.mathematica.package)
file #39506:  A.m added by cbm (201B - application/vnd.wolfram.mathematica.package)
file #39507:  C.m added by cbm (181B - application/vnd.wolfram.mathematica.package)
file #39508:  B.m added by cbm (201B - application/vnd.wolfram.mathematica.package)
file #31704:  inheritance.tar added by cbm (20KiB - application/x-tar)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by genuinelucifer (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by cbm (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-01-19 cbm Attached File- => Added D.m, #39509
    2017-01-19 cbm Attached File- => Added A.m, #39506
        Attached File- => Added C.m, #39507
        Attached File- => Added B.m, #39508
    2016-11-01 mtmiller StatusNone => Confirmed
        Operating SystemGNU/Linux => Any
    2014-07-11 cbm Attached File- => Added inheritance.tar, #31704

    Back to the top

    Powered by Savane 3.3