MATLAB Answers

Bug in subsref overloading

9 views (last 30 days)
Paul
Paul on 8 Dec 2016
Commented: Paul on 13 Dec 2016
Let us first show expected behaviour:
classdef GoodDemo
properties
st;
end
methods
function obj = GoodDemo()
obj.st = struct('x', {1,2,3});
end
end
end
good = GoodDemo;
disp(good.st(2).x); % --> 2
disp({good.st.x}); % --> [1] [2] [3]
However, when we overload subsref (just let it return the built-in output, nothing fancy) things break:
classdef BugDemo
properties
st;
end
methods
function obj = BugDemo()
obj.st = struct('x', {1,2,3});
end
function varargout = subsref(obj, s)
[varargout{1:nargout}] = builtin('subsref', obj, s);
end
end
end
bug = BugDemo;
disp(bug.st(2).x); % --> 2
disp({bug.st.x}); % --> [1]
The problem seems to be that in the overloaded subsref somehow `nargout == 1`. Anything I am doing wrong here?
I found a bit of a crazy workaround, and the most problematic thing about it is it is only supported from 2015b onwards. The workaroud is to also overload the `numArgumentsFromSubscript` with -- big surprise -- its built-in value:
classdef WeirdFixDemo
properties
st;
end
methods
function obj = WeirdFixDemo()
obj.st = struct('x', {1,2,3});
end
function varargout = subsref(obj, s)
[varargout{1:nargout}] = builtin('subsref', obj, s);
end
function n = numArgumentsFromSubscript(obj, s, ic)
n = builtin('numArgumentsFromSubscript', obj, s, ic);
end
end
end
weird = WeirdFixDemo;
disp(weird.st(2).x); % --> 2
disp({weird.st.x}); % --> [1] [2] [3]
This works for Matlab 2015b+. Is there a way to get this working for earlier versions of Matlab? I tried setting `nargout` explicitly, but that has no effect at all.

  9 Comments

Show 6 older comments
per isakson
per isakson on 8 Dec 2016
A Guide to MATLAB Object-Oriented Programming by Andy H. Register includes extensive discussions on subsasgn and subsref. The book was published the year before Matlab introduced the new Class Object System. That's really unfortunate timing.
I found this sentence in a review at Amazon "- is nargout really as broken as it seems?" &nbsp
per isakson
per isakson on 8 Dec 2016
"So I assume my bug report is "not publicly accessible" to you." &nbsp Your request will be processed. It will not be automatically included in the "bug-database". I believe that most issues are included, but that only an appropriate selection are on public display.

Sign in to comment.

Accepted Answer

David Foti
David Foti on 9 Dec 2016
Here is a little more explanation and possibly something that might help with the earlier MATLAB releases. The numel function was originally introduced before 2000 as a means of telling MATLAB how many elements to expect or request from an overloaded subsref using dot and a field or property name. It was given a default implementation that returned the number of elements in the array being subscripted. This worked for object arrays that wanted to return one array for each element in the object array. If the class wanted to emulate a numeric array using a scalar object but have fields that applied to the whole array, it could overload numel to return 1. This solution didn't always work well for more complicated forms of indexing or for what some people wanted to do with brace or cell indexing. That led to the new design that provides more information and allows the class to handle more kinds of indexing correctly.
Another motivation for the new function was the fact that numel was such a nice simple name for getting the number of elements in an array that it started getting used as a better alternative to prod(size(X)) as a way to get the total number of elements in arrays. However, classes that needed to overload numel to return 1 for subref didn't return the right value for the total number of array elements.
I don't know what your actual class needs in terms of subscripting (I assume the example is heavily simplified), but if you want something similar to what you have in your example and can live with numel not returning the true number of elements in your array, then you could overload numel to return the number of elements in st rather than the number of elements in obj. It would look something like:
classdef NumelFixDemo
properties
st;
end
methods
function obj = NumelFixDemo()
obj.st = struct('x', {1,2,3});
end
function varargout = subsref(obj, s)
[varargout{1:nargout}] = builtin('subsref', obj, s);
end
function n = numel(obj)
n = numel(obj.st);
end
end
end

  1 Comment

Paul
Paul on 13 Dec 2016
It feels a bit strange to use this workaround because I overloaded `size` to return the size of another attribute than for which I am now overloading `numel`, but based on a few tests I think this could more or less work. At least the gained functionality certainly justifies the hack. Thanks very much for the explanation too.

Sign in to comment.

More Answers (1)

Philip Borghesani
Philip Borghesani on 8 Dec 2016
I don't think there is anything new here or any new bugs here. There was a design flaw with how numel was used to implement the number of outputs from subsref in a comma separated list context, that was fixed by adding the function numArgumentsFromSubscript in R2015b. There is no way to get your desired output in previous versions of MATLAB.
To maintain compatibility with existing classes that implemented subsref, numArgumentsFromSubscript is only used when it is implemented by a class if the class implements subsref. The builtin returns the number of outputs that would be expected from the indexing operation passed as inputs provided there was no subsref function.

  1 Comment

Paul
Paul on 9 Dec 2016
OK. So the element of surprise was designed.

Sign in to comment.

Sign in to answer this question.


Translated by