Why “too many output arguments” when defining MATL

Question

I am trying to extend the MATLAB containers.Map class by subclassing it and adding an additional method with 0 outputs, but I encounter the "too many output arguments" error when executing the method. This is not specific to the new method implementation--any additional method that extends containers.Map() with 0 outputs will generate this error.

Specifically, the error is encountered when executing,

obj = Containers();
obj.testfun();

For the following class definition,

classdef Containers < handle & containers.Map
    methods       
        % Test function to display keys.
        function testfun(obj)
            obj.keys(); % dumby thing to execute with incoming object.
            disp('it works!');
        end
    end
end

However, if we slightly modify it to output at least one argument,

classdef Containers < handle & containers.Map
    methods       
        % Test function to display keys.
        function dumby = testfun(obj)
            obj.keys();
            disp('it works!')
            dumby = 1;
        end
    end
end

It will execute correctly. The error appears to happen specifically when subclassing containers.Map. If it matters, I am using MATLAB R2014b. Any suggestions as to how to resolve this issue?

Answer 1

Don't try to subclass containers.Map. This is just my opinion, but MathWorks should have made it Sealed so that you just couldn't.

What's going on here is that when you type a.b, or a(b) or a{b}, that is translated into a call to the method subsref. All objects have that method. See doc subsref for more detail on exactly how MATLAB calls subsref but be warned - it's quite complicated.

Now if you want to customize the behaviour of your class, you can overload subsref by providing your own implementation. containers.Map does this, as it needs to support indexing by keys, which is not typical for other MATLAB classes.

I can't tell you precisely how subsref for containers.Map is implemented, as it's a built-in class so I can't see the code. But I'm guessing, from the behaviour you're seeing here, that at some point it's trying to work out whether .testfun() is a call to a method testfun, or a property testfun, or a field testfun, or something else, and one of the things it's doing is to see whether it is being called with output arguments and changing its behaviour accordingly.

This is a great example of where you're not really able to subclass the object without knowing (and possibly modifying) its internals, which is why I suggest that MathWorks might better have made this Sealed to prevent you from trying. In any case, you're not going to be able to subclass it with the behaviour you want, without a few workarounds (i.e. implementing your own overloaded subsref for your Containers class in order to make it work how you want) and a bit of reverse-engineering (i.e. second-guessing the internals of the subsref method of containers.Map).

Instead, you might try using an Adapter pattern, by creating your own class with a containers.Map as a private (maybe hidden) property, then implementing methods and properties that just pass through their arguments and outputs to the underlying containers.Map. Finally, implement your own methods as well.