Short-short version
Is it possible to get an handle to a subclass of Copyable rather than getting a copy?
Context
I have a class hierarchy that i want to have Copyable.
classdef A < matlab.mixins.Copyable
properties
stuff;
end
methods
function action(self)
% ...
end
end
end
Various subclasses provide variations on the main behavior, and a particular subclass works to aggregate several of those behviors for sequenctial application
classdef multiA < classA
properties
nElements = 1;
elements;
iElement = 0;
currentElement;
end
methods
function self = multiA()
end
function addElement(self, fhdl)
if self.nElements == 0
self.nElements = 1;
self.elements = {fhdl}; % Store handles to constructors
else
self.nElements = self.nElements + 1;
self.elements(self.nElements) = fhdl; % Store handles to constructors
end
end
function nextElement(self)
if self.iElement < self.nElements
self.iElement = self.iElement + 1;
fhdl = self.elements(self.iElement);
self.element = fhdl(); % instantiate with constructors
end
end
function action(self)
if self.iElement > 0 && self.iElement <= self.nElements
self.currentElement.action(); % Pass use request to constructed objects
end
end
end
end
The user is expected to build up objects with addElement, and work through the list with nextElement invoking the behavior of the contained objects as needed with `action.
multi = multiA();
multi.addElement( #OneSubClass );
multi.addElement( #AnotherSubClass );
multi.addElement( #ThirdSubClass );
% ...
multi.nextElement();
multi.action();
The problem emerges
The multiA class passes some basic unit tests and I started trying to apply it. And it seemed to be working. Then I get a situation where multi.action() seems to be flipping unpredictably back and forth between two behaviors.
It seems unlikely, but just conceivable that somehow the object of type OneSubClass is sticking around after I have moved on to AnotherSubClass.
The (wrong?) solution
Write a unit test which captures the handle of each element as it is instantiate and checks that this remains the handle in use until the next one is instantiated. Something like:
multiA.nextElement();
ehdl = multiA.currentElement;
% do things
testCase.veriftySameHandle(multiA.currentElement,ehdl);
Alas ehdl seems to be a copy of the stored element rather than a handle to it even though I have not explicitly invoked copy(). (I say that because ehdl retains the state of the contained object at the time of nextElement() while the fresh access of currentElement shows the expected changes.)
Is there a way to force the retention of a handle to an object derived from matlab.mixins.Copyable?
Related
I'm having a weird problem using object oriented matlab, and I'm not sure if I'm completely missing something, or I've hit some unusual behaviour.
I have a superclass defined as follows:
classdef (Abstract) AbstractSimulationData < matlab.mixin.Heterogeneous
properties (Abstract)
name
data
end
properties
timeStamp = -1
end
methods (Abstract)
CalculateData(obj, t)
end
methods
function data = GetData(obj, t)
if obj.timeStamp == t.t
data = obj.data;
else
obj.timeStamp = t.t;
obj.CalculateData(t);
data = obj.data;
end
end
end
end
When the concrete class implements the method CalculateData I intend it to set the superclass property data.
Two concrete classes from this are:
classdef A < AbstractSimulationData
properties
name = 'A'
data = []
end
methods
function obj = A
% No special initialisation
end
function CalculateData(obj, t)
test = t.B.GetData(t)
obj.data = rand(2,10);
end
end
end
And:
classdef B < AbstractSimulationData
properties
name = 'B'
data = containers.Map
end
methods
function obj = B
% No special initialisation
end
function CalculateData(obj, t)
if isempty(obj.data)
obj.data('left') = 1;
obj.data('right') = 2;
end
% Other operations
end
end
end
Within the A.CalculateData method I call the GetData method for B. This in turn calls the B.CalculateData method.
Now, as it filters back up, the data property gets set correctly so that B.GetData returns the value that was set in B.CalculateData.
But, when I go the next step up to A.GetData it returns [], the initialised value. Going through debug mode, the calculations definitely work in A.CalculateData and it seems to set data correctly, but when it jumps back up to the superclass obj.data is the default value from A.
A minimum working example to get this behaviour:
t.B = B();
t.t = 1;
a = A;
a.GetData(t);
>> test =
Map with properties:
Count: 2
KeyType: char
ValueType: any
>> ans =
[]
This is all part of a pretty big project, so it's hard to give the full context, but if it's possible from this, can someone explain why setting superclass data works for B but not A?
If it makes a difference B is returning a container.Map and A is returning 2xn matrix.
As far as I can tell from the documentation, it should work.
I like the OO programming style that matlabs App Designer uses (or at least the way I'm using it). Now I'm wondering if I can use the same style in my "normal" matlab class.
What I have now:
classdef myClass
properties
myVar;
end
methods
function Main(obj)
obj.myVar = "a";
obj = DoSomething(obj);
disp(obj.myVar) % outputs "c"
end
function obj = DoSomething(obj)
if(obj.myVar == "a")
obj.myVar="c";
else
obj.myVar = "b";
end
end
end
end
Which can be called externally using:
myClassInst = myClass;
myClassInst.Main()
I would like to get rid of all the "obj = " in the classdef, as is possible in App Designer. So something that would look like this:
classdef myClass
properties
myVar;
end
methods
function Main(obj)
obj.myVar = "a";
DoSomething(obj); % Just call the function without "obj = "
disp(obj.myVar) % outputs "a" because I didn't overwrite obj
end
function DoSomething(obj)
if(obj.myVar == "a")
obj.myVar="c";
else
obj.myVar = "b";
end
end
end
end
The equivalent of this seems to work in App Designer. So it appears you can modify variables in a class (instance?) in App Designer, while also being able to access the modified variable without explicitly overwriting your old class instance.
I noticed App Designer has all methods an properties set to (Access = private), though I'm not sure that has anything to do with it. Of course if I set everything to private, then I can't access the Main() method from outside anymore.
So my question is, how can I program in "normal" matlab, the same way as is possible in App Designer?
EDIT:
The following works in App Designer (I left out the methods/properties for the GUI elements):
classdef tmp < matlab.apps.AppBase
properties (Access = private)
myVar; % Description
end
methods (Access = private)
function doSomething(app)
if app.myVar == "a"
app.myVar = "c";
else
app.myVar = "b";
end
end
end
% Callbacks that handle component events
methods (Access = private)
% Code that executes after component creation
function startupFcn(app)
app.myVar = "a";
doSomething(app);
disp(app.myVar); % outputs "c"
end
end
end
You definitely can! All you have to do is inherit from the handle class, as opposed to a value class which is the default for matlab. You can also define private and public methods as in other languages.
The only thing you have to do is:
classdef myclass < handle % this is how you inherit from base class
properties
public_property
end
properties (Access=private)
private_property
end
methods
function obj = myclass() % class constructor
...
end
function public_function()
...
end
end
methods (Access=private)
function private_function()
...
end
end
end
Now every time you pass an object of this class to a function, you are not passing it by value, you are passing by reference (as you might be used to from python) and modifying it's properties modifies them also in the original object.
You need to inherit (< at the top of the class) from a handle class
classdef myClass < handle
properties
var
end
methods
function obj = myClass( varargin )
% Constructor function, called automatically when object is created
end
function someFunction( obj )
obj.randomizeVar(); % Equivalent to randomizeVar( obj );
end
function randomizeVar( obj )
obj.var = rand();
end
end
end
See the documentation for the difference between a "handle" and "value" class:
A value class constructor returns an object that is associated with the variable to which it is assigned. If you reassign this variable, MATLABĀ® creates an independent copy of the original object. If you pass this variable to a function to modify it, the function must return the modified object as an output argument. For information on value-class behavior, see Avoid Unnecessary Copies of Data.
A handle class constructor returns a handle object that is a reference to the object created. You can assign the handle object to multiple variables or pass it to functions without causing MATLAB to make a copy of the original object. A function that modifies a handle object passed as an input argument does not need to return the object.
Moreover, if you edit matlab.apps.AppBase, the class which you app designer code inherits, you can see that the first line is
classdef AppBase < handle
So you are literally doing the same thing, without the AppBase middle-man.
I want to call a method from a class. For example, I have:
classdef SweepLine
properties
y;
count;
sections;
end
methods
function obj = SweepLine(y)
obj.y = y;
obj.count = 0;
end
function AddSection(obj, section)
obj.count = obj.count + 1;
fprintf('%d\n', obj.count);
fprintf('Indext is: %d\n', section.index);
obj.sections(obj.count) = section;
end
end
end
When I call the method AddSection in a different script, like so:
AddSection(sweepLine, Sections(i)); % Sections contains 10 section objects
I got this error:
The following error occurred converting from Section to double:
Error using double
Conversion to double from Section is not possible.
Error in SweepLine/AddSection (line 20)
obj.sections(obj.count) = section;
I guess this is because I did not do the memory preallocation, but I'm still not sure.
I just moved to MATLAB OOP from Java, and feel that there are a tons of things that are hard to get well with.
Any help about this question and MATLAB programming is really appreciated!
It looks like you are trying to concatenate the sections array with a new value. When you do this, you are assuming that obj.sections has already been allocated, and by doing that assignment you are getting that error. As such, what you have suspected is correct. To get around this, try doing this statement instead in your AddSections method for your class:
obj.sections = [obj.sections section];
This will concatenate section with the currently established obj.sections. This essentially adds section to the end of the array, which is what your previous code is doing. This is safe for empty arrays as well as allocated ones.
I would also recommend that your SweepLine class inherit from the handle class. I'm assuming that when you call AddSection, you don't want the object to be returned. You just want to modify the object, and return nothing...right? If this is the case, then you must inherit from the handle class. However, if you are returning the current instance of the object after each method call, then this isn't required.
In any case, you should do this:
classdef SweepLine < handle
properties
y;
count;
sections;
end
methods
function obj = SweepLine(y)
obj.y = y;
obj.count = 0;
end
function AddSection(obj, section)
obj.count = obj.count + 1;
fprintf('%d\n', obj.count);
fprintf('Index is: %d\n', section.index);
obj.sections = [obj.sections section];
end
end
end
In Matlab, I would like a data structure that looks like so:
DataStruct
.model
.Q
.Qchol
.
.
.system
.
.
The structure may well be a class, although I don't really need all the other functionality that goes with oop.
But I require
If Q is assigned something, then automatically Qchol = cholcov(Q).
If Qchol is assigned something, then automatically Q = Qchol' * Qchol.
Meanwhile, both Q and Qchol are stored for fast read-access
And Q and Qchol are writable through simple assignment, e.g.: DS1.mod.Q = value
I know I can make model a class, and have set/get methods for Q and Qchol. However, this really seems like an overkill for just two matrices (plus maybe some more fields). Also Matlab warns me that I should not access other properties during in a set method.
So: What is the best way to have such data structures, preferably without warnings?
You basically want assignment (DS1.mod.Q = value) to have side-effects, which inevitably implies a setter, and hence a class. You should either drop this requirement, or write a class.
If you wish to avoid definition of properties in the class declaration, you could use Dynamic Properties, which allows you to add properties at runtime (although with some telltale syntax addprop()).
EDIT
Patric, the problem goes deeper then just M-lint. Consider the following class:
classdef cantInstantiateMe < handle
properties
x
minus_x
end
methods
function obj = cantInstantiateMe(x)
obj.x = x; % <-- this calls set.x(), which calls set.minus_x(), which calls set.x(), ...
obj.minus_x = -x;
end
function set.x(obj, value)
obj.x = value;
obj.minus_x = -value; % <-- this gives an M-Lint warning
end
function set.minus_x(obj, value)
obj.minus_x = value;
obj.x = -value;
end
end
end
This class cannot be instantiated, because each setter calls the other setter (this is not Matlab-specific). Trying to instantiate on my machine gives:
??? Maximum recursion limit of 500 reached. Use set(0,'RecursionLimit',N)
to change the limit. Be aware that exceeding your available stack space can
crash MATLAB and/or your computer.
At this point I think you have two options:
Make either Q or Qchol a dependent property. This will come at the cost of re-calculating the dependent property each time you read-access it.
Use some private shadow properties e.g. shadow_Q and shadow_Qchol which will be set when the setter for the public property is called, and returned when their getter is called. Similar to:
function set.x(obj, value)
obj.shadow_x = value;
obj.shadow_minus_x = -value;
end
function value = get.x(obj)
value = obj.shadow_x;
end
Note the I did not test this properly, so I don't know all implications in Matlab. In other languages I'm familiar with, this should work fine.
Regarding the warning - my approach is that it is safe to disable the warning, as long as you really know what you are doing.
As suggested by #bavaza, one way to implement this is to use a dependent property with corresponding shadow private properties.
Below is the code implementing the inner data structure (inspired by this post). You need to use composition to make an instance of this class a property of the outer object:
classdef Model < handle
properties (Dependent)
Q
Qchol
end
properties (Access = private)
Q_
Qchol_
end
methods
function obj = Model()
end
function val = get.Q(obj)
val = obj.Q_;
end
function val = get.Qchol(obj)
val = obj.Qchol_;
end
function set.Q(obj, val)
obj.Q_ = val;
obj.Qchol_ = cholcov(val);
end
function set.Qchol(obj, val)
obj.Qchol_ = val;
obj.Q_ = val'*val;
end
end
end
Setting one value using the exposed dependent properties affects both underlying variables:
>> m = Model
m =
Model with properties:
Q: []
Qchol: []
>> m.Qchol = rand(3)
m =
Model with properties:
Q: [3x3 double]
Qchol: [3x3 double]
Is there a better way to implement copy construcor for matlab for a handle derived class other than adding a constructor with one input and explicitly copying its properties?
obj.property1 = from.property1;
obj.property2 = from.property2;
etc.
Thanks,
Dani
There is another easy way to create copies of handle objects by using matlab.mixin.Copyable. If you inherit from this class you will get a copy method which will copy all the properties for you.
classdef YourClass < matlab.mixin.Copyable
...
a = YourClass;
b = copy(a); % b is a copy of a
This copy method creates a copy without calling constructors or set functions of properties. So this should be faster. You can also customize the copy behavior by overriding some methods.
If you want a quick-and-dirty solution that assumes all properties can be copied, take a look at the PROPERTIES function. Here's an example of a class that automatically copies all properties:
classdef Foo < handle
properties
a = 1;
end
methods
function F=Foo(rhs)
if nargin==0
% default constructor
F.a = rand(1);
else
% copy constructor
fns = properties(rhs);
for i=1:length(fns)
F.(fns{i}) = rhs.(fns{i});
end
end
end
end
end
and some test code:
f = Foo(); [f.a Foo(f).a] % should print 2 floats with the same value.
You can even use
try
F.(fns{i}) = rhs.(fns{i});
end
which makes the method more useful