Argument validation for class methods

Is there a best practice for validating (or not validating) the 'self' arguments in class method definitions?

Consider:

classdef my_class  < handle
    properties
        A;
    end

    methods
        function obj = my_class
            obj.A = 0;
        end
        function add_to_obj(obj, B)
            arguments
                obj my_class;   %This seems unnecessary
                % obj;          %Alternately we could omit the 'class' specifier
                B (1,1) double;
            end
            obj.A = obj.A + B;
        end
    end
end

The class specification of the obj argument seems superflous and should be self-evidently true. Are there performance implications for leaving it in there (i.e., if I'm calling add_to_obj a lot)? Should I just leave out the specifier (essentially bypassing the argument validation)?

Answer 1

[Steven Lord]

The class specification of the obj argument seems superflous and should be self-evidently true.

Not necessarily. The first input argument to a class method is not always required to be an instance of that class! There are two common patterns where this may not be the case. Let's take a sym object as an example.

syms x

This command calls the plus method for the sym class, as we can tell using the which function.

y = x + 1

y = 

which('plus(x,1)')

/MATLAB/toolbox/symbolic/symbolic/@sym/plus.m  % sym method

This also calls the plus method for the sym class, even though 1 is not a sym. It doesn't call the plus defined for double arrays.

z = 1 + x

z = 

which('plus(1, x)')

/MATLAB/toolbox/symbolic/symbolic/@sym/plus.m  % sym method

which('plus(1, 2)')

built-in (/MATLAB/toolbox/matlab/ops/@double/plus)  % double method

Another common pattern is when class precedence is involved. [I suppose the example above simplifies down to this as well, since as stated on that documentation page double is always inferior to classes defined using classdef, which is the case for the sym class.] The graph object in MATLAB has an overloaded plot method that can accept an axes handle as its first input.

g = graph(bucky);
ax = axes;
plot(ax, g)

Despite the first input to plot being an axes object, MATLAB calls the graph plot method.

which('plot(ax, g)')

/MATLAB/toolbox/matlab/graphics/math/@graph/plot.m  % graph method

This is because the graph class states that the axes class (technically matlab.graphics.axis.Axes) is one of its InferiorClasses (as listed in the metaclass information.) So if both a graph object and an axes object are in a method's argument list, regardless of the order in which they're listed in that argument list, we call graph's method.

q = ?graph;
{q.InferiorClasses.Name}.'

ans = 2x1 cell array
    {'matlab.graphics.axis.Axes'}
    {'matlab.ui.control.UIAxes' }

class(ax)

ans = 'matlab.graphics.axis.Axes'

But to get back to your question about performance, measure it and find out! You'll probably want to use timeit or the Profiler as I suspect the impact with and without the validation is going to be so small tic and toc may not capture it. I strongly suspect that unless your method is very fast (returning a constant value) this probably isn't going to be your bottleneck.

[John]

Thanks for your reply and the thorough response. But to play Devil's Advocate, you've partially sidestepped the original question. All of the examples (plus, plot, etc.) do not use arguments declarations for validation. If the method in question is written to support varargin inputs, or like plus are designed with internal calls design to sort out how to manage the input arguments, you're probably not using an arguments declaration anyhow.

I'll also grant that the overhead from doing the validation will be minimal in most applications. It's probably safer to include the validation if you expect users to invoke the method with

foo = my_class;
add_to_obj(foo, 5);

That way you'll get an error thrown during validation rather than a problem further down the line.

As an aside, I really like arguments as I find it much cleaner and succinct than working with inputParser in many situations. It would be useful to have an additional builtin validator, like mustBeEmptyOrA (e.g., allows an empty default, but if it isn't empty is has to satisfy mustBeA). This comes up often enough that it creates a dependency issue when distributing code.

[Steven Lord]

I used the plus function / method in my example, but your add_to_obj(obj, B) method looks like it is adding together obj and B, doesn't it? So it could be called plus, couldn't it?

Please contact Technical Support directly using this link to submit an enhancement request for mustBeEmptyOrA. When you do, please describe your use case (especially how the lack of it proves to be a problem when you distribute your code.) The developers benefit greatly when designing new features if they have real-world usage stories to help them consider design trade-offs.

[John]

My example was really just intended as a minimal demonstration. The real applications were quite different. But thanks nontheless. I'll put in a enhancement request, as you suggest.