Data tends to survive longer than code. So I want to save my objects as struct.
The idea is to overwrite the saveobj method calling struct recursively on itself.
classdef foo < handle
properties
Data = 12
end
methods
function data = saveobj(o)
data = struct(o);
end
end
end
I now call:
>> bar = foo;
>> save('test', 'bar')
>> bar2 = load('test')
>> class(bar2.bar)
'foo'
However the saved object is still of type foo. Any help figuring out where I screwed up would be appreciated. Thanks
In case it matters I'm using R2012a on RHLE6
The "problem" is that despite the documentation implying that the output from saveobj gets saved with no knowledge that it originated from an object, that is not the case. The structure knows that it came from an object, and when loaded will get passed to a loadobj method if it exists, or the constructor if it doesn't.
One way to overcome this is to overload save, and then call save on the struct within the save method of the object; another is to have a method that returns a struct and then call save on that struct. There are probably also some hacks that can be done to make it a little more automatic, which is most likely what you really want.
I found a truly ugly hack-around, which might help somebody. Due to its ugliness I will however still wait for an answer.
As Phil already pointed out is the class name still stored with the file. However we can trick matlab with an other file with the same name.
My original class looks like this:
classdef foo < handle
%// This is the original class used to some stuff and it holds
%// important data. But I lost it over time...
properties
Data = 12
end
methods
function data = saveobj(o)
for f = properties(o)'
data.(f{1}) = saveobj(o.(f{1}));
end
end
end
end
Now, since I assume I don't have the original source anymore I can use a dummy class to load the data.
classdef foo < handle
%// This is the pretender class source. Since I lost the source of
%// the original class.
methods (Static)
function data = loadobj(data)
global DATA
DATA = data;
end
end
end
The load will naturally fail, but I can extract the struct feed into the loadobj method by calling:
global DATA
As I said a very ugly solution. That's why I'll wait till somebody smart comes around and finds a better way to solve this problem, but I thought I post it in case it helps somebody.
Another hack-around might be to save the class-code while saving the object.
For loading the object of your class, you could first load the code, store it as a m-file and then load the object of the class.
Related
I tried to change an attribute value of a class by invoking one of its member function:
p1 = tank();
p1.checkOri(p1);
And in the class definition, I have that static method:
classdef tank
properties
value
...
end
methods
...
methods (Static)
function obj = checkOri(obj)
if (CONDITION) %the thing I want it to do
obj.value = EXPRESSION;
...
Yet this checkOri method is not working. But if I write this method in the main file, or to say altering the value of p1-the instance of class tank-it works perfectly:
p1 = tank();
p1.checkOri(p1);
if (CONDITION) %the thing I want it to do
p1.value = EXPRESSION;
It works perfectly.
I wonder what caused this. From my experience with other programming languages, invoking method should have worked, is it because of some tricks with Matlab syntax or static method? How could I fix it so that this method would work?
So, as #Navan in the comment said, handle class could be a solution.
It appears Matlab has a similar parameter concept with Java and C++, arguments modified in a function/method only remains that modification inside the function/method.
For this class, I simply added < handle in the head of class definition and it worked:
classdef tank < handle
properties
...
But I am not sure if that is the only solution, there might be better ways to do this. So I'll leave that question open, you are more than welcomed to post your opinion:D
In MATLAB, the call
p1.checkOri();
is equivalent to
checkOri(p1);
In both cases, the class method checkOri is called for the class of object p1, passing p1 as first argument to the function by value.
Because p1 is passed by value, any changes made to it inside the function are not seen by the object in the calling workspace. Therefore, one typically does
p1 = checkOri(p1);
This way, the object that was passed by value and modified inside the function is passed back out and assigned to the variable that held the original object.
If the method is written as follows:
function obj = checkOri(obj)
%...
end
then MATLAB will optimize the above function call such that no copy of the object is actually made. Note that both in the function declaration and in the function call, the input and output variable is the same.
As already discovered by OP, the above does not hold for handle classes, classes that inherit from handle. These classes act as if they are always passed by reference, and any change made to them in any workspace will be reflected in all other copies in other workspaces.
Also assigning to a member variable does not follow the above, such that
p1.value = 0;
modifies object p1.
For more information on the difference between value classes and handle classes see this other question.
It is my first time asking a question here and I am quite new to MATLAB. So, I am sorry in advance if my explanation is faulty or insufficient. I'll be happy to hear any advice to improve myself.
I would like to create a class which has an array of a certain size. Let's call this class 'MyClass'. My class is as follows:
classdef MyClass
properties
A = array2table(zeros(ArraySize,1));
end
end
The variable ArraySize is defined in my main.m file and i want to create an object from this class within the same file:
ArraySize = 10;
MyObject = MyClass;
However, the class I created does not recognize the ArraySize variable. Could somebody tell me if there is an easy way to achieve this?
So far, I tried to make it a global variable, I tried using 'load' function to pass parameters between files. I tried defining the class inside a function. None of them seem to work. I read about 'handles' in forums and i got the idea that it somehow can be related to the solution of my problem, but I do not really know how to work with them. What I understood so far is that handles correspond to pointers in C++. I would like to know if they can be used to solve my problem and if so, how exactly.
Thanks in advance.
You should just write your constructor to accept ArraySize as an input argument and then initialize the value A inside of your constructor.
classdef MyClass
properties
A
end
methods
function self = MyClass(arraySize)
self.A = array2table(zeros(arraySize,1));
end
end
end
And then instantiate your class
myObject = MyClass(ArraySize);
And with regards to handle classes, check out this page of the documentation to see recommendations on when to use handle and value classes.
I have some big handle objects hierarchy, for example
classdef A < handle
b;
c;
end
classdef B < handle
d;
e;
end
classdef C < handle
f;
g;
end
a = A;
where a,b,c,d,e,f are all instances of their respective classes. Eventually, there are basic data types (vectors or scalars of, say, double).
I need the save of a to hold all the information about a,b,c,d,e,f, in a way that can be restored later.
Runtime is not an issue for me right now.
Development time is an issue.
How can I easily create a save of the top A type object to disk? (a deep copy, to disk).
I want it to happen automatically (built in), somewhat like java's serialize maybe, without me having to change some save method for every change I make in the classes' structure.
When saving objects with MATLAB using the built-in save, it will automatically save a "deep-copy" in that it saves all properties of the object and if any of those properties are also objects or arrays of object, they will themselves be serialized. The objects can then easily be loaded again using the built-in load function. It is worth noting that in order for an object of a custom class to be loaded properly, the class definition must be on the path when calling load.
save('output.mat', 'a')
fromdisk = load('output.mat');
If you want to customize the saving or loading functionality of your class, you can overload the saveobj and loadobj methods, respectively.
I'm trying to write a class that wraps around a serial port to read a sensor:
classdef sensor < handle
properties
Value
s
end
methods
function obj = sensor(port)
obj.s = serial(port);
obj.s.BytesAvailableFcn = #(o,e) obj.getData;
fopen(obj.s);
end
function delete(obj)
disp('called destructor');
try
fclose(obj.s);
delete(obj.s);
end
end
function getData(obj)
obj.Value = fscanf(obj.s, '%d');
end
end
end
When I try to clear the workspace, the destructor never gets called:
>> foo = sensor('COM1');
>> clear foo % should disp() something!
Based on my previous experiences, there must still be a reference to foo. Turns out this is embedded in the serial port foo.s:
>> ports = instrfindall;
>> ports.BytesAvailableFcn
ans =
#(o,e)obj.getData
Once I clear out the BytesAvailableFcn, i.e.,
>> ports.BytesAvailableFcn = '';
and then clear all, I get my called destructor displayed.
How can I break this circular reference and get my destructor to get called? If the destructor doesn't get called, the serial port stays bound.
The problem is not quite that you have a circular reference; MATLAB should in theory catch those. The issue is that the circular reference goes via Java, and MATLAB can't catch it.
In more detail - your serial object contains a Java object internally, which is the real thing that captures the connection to the serial port. When you set its callback, MATLAB sets the callback of the underlying Java object. If the callback is to a method of an object that contains the serial object as a property, then you have a circular reference that goes via the underlying Java object. When you call clear, MATLAB checks for circular references, and if they were all in only MATLAB it would catch them, and call the destructor - but it doesn't catch them as it goes via Java.
One solution is to explicitly call the destructor, and perhaps that's not too much trouble.
Another workaround might be to simply not have the callback as a method of the class - perhaps it could just be a regular function, as it doesn't really seem to need any information from the main object itself other than the reference to the serial object. If you would prefer to keep all the code in a single file, perhaps you could create it as an anonymous function (although be careful, as an anonymous function will capture the workspace that it's created in, which depending on where you create it may include a reference to the main object, in which case you'd have a circular reference again.
Edit: Rody's right - my apologies, I read the problem too fast and didn't notice that getData actually sets the Value property rather than just returning the data. Rody's solution in his answer may be an alternative workaround, but like he says - yuck. I'd just call delete manually.
Intriguing problem! :)
I found a workaround, but it's not going to be pretty.
You cannot use an anonymous function. That would capture the local workspace, which will contain a reference to obj. You'll have to use one level of indirection (to a Static method, otherwise, you'd have the same problem).
This static method can safely return a function handle. This function handle is to a function, which has to be passed the instrument object.
Setting the Value property is of course impossible without passing a reference to the object, so, you'll have to create a global state in the function, a variadic call signature, and a getter for the Value property.
I have the feeling I've over-engineered this a bit (it's Friday after all), so if anyone sees a simpler way, please correct me. Anyway, here's what I mean:
classdef sensor < handle
properties
s
end
properties (Dependent)
Value
end
methods
function obj = sensor(port)
obj.s = serial(port);
% You cannot use function handle without implicitly passing obj into
% it. Instead, get a function handle from another function, one that
% does not have this problem:
obj.s.BytesAvailableFcn = sensor.getGetData(obj.s);
fopen(obj.s);
end
function delete(obj)
disp('called destructor');
try %#ok<TRYNC>
fclose(obj.s);
delete(obj.s);
end
end
% Use a getter for Value, so that whenever you query the Value property,
% you get the most recently read sensor data
function V = get.Value(obj) %#ok<MANU>
V = getData();
end
end
% Use indirection to a Static method, to avoid referencing obj implicitly
methods (Access = private, Static)
function f = getGetData(S)
f = #(o,e)getData(S);
end
end
end
% The actual sensor reader
function data = getData(S)
persistent port
if nargin == 1
port = S; return; end
try
data = fscanf(port, '%d');
catch ME
% ...
end
end
Just....yuck.
UPDATE:
This is a known bug - link requires a login to Mathworks to access it.
Summary of bug report
An instance of a MATLAB user-defined
class saved to a MAT file using
Version 7.6 (R2008a) might not load
properly if one of its property values
is an instance of a different MATLAB
class.
Briefly, Mathworks reports that a previously saved top level custom object may be loaded incorrectly (as described below) and that the error occurs on the SAVE step. So, the data is corrupted inside the MAT file.
From my experience this seems to be intermittent. In one data analysis application I wrote out of 75 MAT files 37 were saved with this corruption :(
Be careful with user defined objects. I added the following test on save to make sure that the data is not corrupted
save('MAT_file_name.mat');
tmp=load('MAT_file_name.mat');
if ~isa(tmp.bb,'superClass')
msgbox({'THE FILE WAS NOT SAVED PROPERLY', ...
' ', ...
[' MAT_file_name.mat',]})
end
Orginal Question
Here I am using MATLAB 2008a. This subtle bug is fixed in MATLAB-2009a.
Anyway, the way my two classes are defined, the save/load cycle causes the variables of one class (superClass) to be loaded as variables of my second class (propClass).
Example MATLAB (r2008a) Session
>> bb=superClass;
>> whos
Name Size Bytes Class Attributes
bb 1x1 60 superClass
>> save
>> clear
>> clear classes
>> load
>> whos
Name Size Bytes Class Attributes
bb 1x1 60 propClass
After loading matlab.mat, the variable bb has mysteriously changed from superClass to propClass
Class: superClass
This class needs to contain an array of type propClass and here is it's Naive definition
classdef superClass<handle
properties(SetAccess=private)
a = propClass.empty % need to set this property as type propClass
% otherwise the addProp method throws an error
count=0;
end
methods
function self=superClass
%empty class definitionS
end
function addProp(self)
p = propClass;
self.count = self.count+1;
self.a(self.count)=p;
end
end
end
Class: propClass
PropClass is a second class used by the super class. Its definition is not important for this bug.
Question
So, why is superClass being changed to propClass after the load operation in MATLAB-R2008a? Secondly, how can I change the definition of superClass to avoid this symptom?
Note
I ran into this symptom in a larger class I had written and narrowed down the source of the problem. I know it occurs in the MATLAB session described above but it seems that if I add an object to the property array in superClass then the problem disappears.
So, if I call superClass.addProp before saving then the strange change from superClass to propClass doesn't occur.
That's a strange problem! I haven't come across anything like that, but one thing you could try first is to move the initializations of the properties to the constructor:
classdef superClass < handle
properties (SetAccess = private)
a
count
end
methods
function self = superClass
self.a = propClass.empty;
self.count = 0;
end
function addProp(self)
p = propClass;
self.count = self.count+1;
self.a(self.count) = p;
end
end
end
I'm not sure it will have any effect, but that's the only thing I can think of to try. Hope it helps! =)