I think you've already found the relevant documentation that explains what is happening. As to why it is like that, only Mathworks can tell you. In my opinion, there are many design flaws in the way they've implemented OOP (loadobj for example).
However, in your case all your problems come from the fact that you're trying to store arrays of handle objects. This is a bit unusual. Shouldn't your objects be value class instead? With handle classes, I tend to prevent concatenation / array construction by default because the class methods are rarely designed to work with array inputs.
If you do need handle classes then I would modify the class constructor so that it can create the array directly, avoiding the user having to remember to create each array element individually:
classdef primaryClass < handle
properties
x
myContainedClass
end
methods
function obj = primaryClass(varargin)
if nargin == 0
obj.myContainedClass = secondaryClass;
else
sz = [varargin{:}];
obj(prod(sz)) = primaryClass;
obj = reshape(obj, sz);
for idx = 1:numel(obj)-1
obj(idx).myContainedClass = secondaryClass;
end
end
end
end
end
Remember that each method of primaryClass has to be designed to work on arrays of objects, something that is very jarring if you're used to OOP in other languages:
a = primaryClass(5,2,2);
a.somemethod
Best Answer