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.
|
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.
|
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.
|
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"?
|
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.
|
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.
|
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"
Matlab
Octave:
(file #39509)
|
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)
|
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.
|
Tue 01 Nov 2016 05:29:17 AM UTC, comment #3:
The cause of this behavior is right here
http://hg.savannah.gnu.org/hgweb/octave/file/b5407b1ab11a/libinterp/operators/op-class.cc#l81
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)?
|
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.
|
Fri 11 Jul 2014 11:09:38 PM UTC, comment #1:
also present in 3.6.4.
|
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
|