[bug #68227] multiple inheritance no longer allowed for handle classes

Please use the bug tracker to post updates to a bug report.  The mailing list is intended as a read-only notification stream.  Info posted to this mailing list address won't appear in the tracker database where it is most useful.

Follow-up Comment #1, bug #68227 (group octave):

I've looked into this for a bit. You're right that bug #50011 is related, but
it's because the fix for that bug was incomplete. 

The real problem is how Octave handles diamond inheritance, not just with
handle classes. To illustrate, if you have a common superclass called
"qquux":


classdef qquux
  methods
    function retval = testfunc (obj)
      retval = 5;
    end
  end
end


such that `bbar` and `bbaz` inherit from 


classdef bbar < qquux
end

classdef bbaz < qquux
end


You'll have an inheritance diamond like so:

       qquux
       /   \
      /     \
  bbar       bbaz
      \     /
       \   /
        ffoo

and you'll get the same error


>> f = ffoo;
>> f.testfunc
error: method testfunc: conflicting definitions in classes 'bbar' and 'bbaz'


Each internal representation of a class contains the methods that are defined
by that specific class, but not the methods of their superclasses. So `ffoo`,
`bbar` and `bbaz` contain no methods, but `qquux` contains one method. In the
case of handle, `delete` is one of its registered methods. 

Octave uses a lazy approach for method resolution on classdefs by searching
the superclasses only when necessary. When a method is called, the object that
is the dominant argument is first searched for a caller method. In both cases,
that's `ffoo`'s method list that is being searched. Because the `delete`
method isn't found in `ffoo`, then the superclasses of `ffoo` are searched.
The handle class is itself a classdef object, so its method map is being
searched. 

Before the patch for bug #500011 was submitted, the first result for a method
was returned. The patch papered over the immediate issue by emitting an error
if more than one method definition was found, but that broke diamond
inheritance in all but the most trivial of cases (the no-method case).

A simple-ish fix is to check if the two methods returned by a classdef method
search are part of the same classdef. I will attach a patch shortly that does
just that after I add some tests.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?68227>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQk97aszIMMAvLLwm6qLAuaBUf3TgUCadxMUQAKCRCqLAuaBUf3
ToxbAP9O1CfcvCNLOROriwlwqgE7MJJOOyYBXnFFkmlXujRurwD/f4AO8/v2/OlZ
KHkTgNVB+LcESuw2pbsFxur0FEEUigE=
=O+aY
-----END PGP SIGNATURE-----