loadobj input argument type determination?

All,

Can anyone tell me what drives the type of argument that loadobj() gets? According to the help:

http://www.mathworks.com/help/techdoc/ref/loadobj.html

The input argument, a, can be: The object as loaded from the MAT-file. A structure created by load (if load cannot resolve the object). A struct returned by the saveobj method.

Well my object was saved to a .mat file but now, all of a sudden, after some work on the object's class definition, my loadobj ftn is now getting structures passed to it. What does "if load cannot resolve the object" mean? I did something to my class that caused loadobj to all of a sudden start to get structures but I have no idea what caused it? If I remove the loadobj function and just load the object from the .mat file, load() returns an object; so it must be able to "resolve" the object at some point. I really don't want to go to the trouble of instantiating a new object in loadobj() if a struct is passed and copying all the fields over. Especially when I know the object can be loaded by load()

Very confused. Any help is appreciated. A doc somewhere that I'm missing? I think I've read everything available.

Answer 1

[Richard]

You can think of objects as being saved as a set of pairs of properties and their values. When you load one, it creates a new object and then sets those saved property values into the new object, and then calls loadobj if there is one. If any of the properties does not exist, or errors because a property function rejects the value, then the loadobj will be passed a structure of data.

Have you removed or renamed a property, or changed code to exclude property values that used to be valid? You can also try using the debugger to see if it stops in any of your MATLAB class code while loading.

[Joseph Burgel]

Hi Richard,

Thanks for the response. So if any set or get methods are defined for some properties, they will get called BEFORE loadobj(), correct? This means that as the class definition evolves, code may be required in the set/get methods so they won't fail when presented with legacy persisted objects, correct? Another question: I have a property that was NOT transient in version 1, it also had a set method defined for it. Then, in version 2 of the class, I make the property transient. When I load a version 1 object, that contains a copy of the persisted property, will the set method still get called for that property or will it be ignored because the current definition of the class says that property is transient?

One final objservation: I had a version 1 object saved to a file. I modified the definition of that object's class - several changes. Then, when I tried to load version 1, loadobj() began to get structures. Here's the strange part: Without making any changes to the class, I then loaded a file containing a version 2 object. This version 2 object was created and saved to a file with a class definition exactly the same as when it was loaded. As you might expect, loadobj() got an object argument. Then, without changing anything, I went back a tried to load the version 1 object again and voila! I got an object passed to loadobj(). So, the mere fact that I loaded a version 2 object changed something in ML that allowed loadobj() to recieve a version 1 object instead of a version 1 structure; this, without changing any code whatsoever. Is ML persisting something internally that I reset by loading the version 2 object? If I don't define a loadobj() method, load() was always capable of returning version 1 objects. How can it do this if the class definition has changed so much that loadobj() must get a structure? Any help is appreciated.

[Richard]

Hi Joseph,

Yes, the property set functions are called before loadobj, and you can use these to accept and convert old property data. The transient property will still be set because there is saved data for it: the overall aim of the loading process is to get all the saved data successsfully sent into your new object.

I can't really explain your observations regarding the failing and then working load of a v1 object. Can you reproduce this from a clean MATLAB start? Is it possible that you have persistent variables in your set functions?

Another thing to watch out for is whether MATLAB has cleared and reloaded your class when you change the definition. The class can't be cleared if you have existing variables that contain an instance. If you were testing loading then the class definition reload might lag a test-cycle behind when you thought you made a class change.

[Joseph Burgel]

Hi Richard,

Thanks again for the response. I would have replied earlier. I thought I would get an e-mail if someone replied and I didn't. Regarding your comment:

I can't really explain your observations regarding the failing and then working load of a v1 object. Can you reproduce this from a clean MATLAB start? Is it possible that you have persistent variables in your set functions?

Yes, I do have persistent variables in my set functions and yes, I should know better. I did it despite the ample warnings because it's so convenient on a number of fronts and at the time, it didn't appear to be causing problems. I should have been thinking more about the load process before I did it. I'll remove them and see if that doesn't fix the problem.

Regarding your comment:

Another thing to watch out for is whether MATLAB has cleared and reloaded your class when you change the definition. The class can't be cleared if you have existing variables that contain an instance. If you were testing loading then the class definition reload might lag a test-cycle behind when you thought you made a class change.

I think I'm also running into this on another problem in that some of my objects contain instances of java objects set to Transient properties of the object. These objects have been instantiated on the EDT thread and I have found no way of getting rid of a couple of them "Clear All" , "Clear Java" etc. have no effect. All I get is:

Warning: Objects of DQTree/DQTreeModel class exist - not clearing java

Warning: Objects of DQTree/DQTree class exist - not clearing java

Warning: Objects of dqtable/DQCellEditor class exist - not clearing

I asked a question about this but have not gotten a response. I've resorted to re-booting ML everytime I make changes. This as DRASTICALLY slowed my development

Regarding your Comment:

Yes, the property set functions are called before loadobj, and you can use these to accept and convert old property data. The transient property will still be set because there is saved data for it: the overall aim of the loading process is to get all the saved data successsfully sent into your new object.

Not sure I understand your answer. V2 make the property transient. Because the loaded V1 object had the property as persistent, will the set method be called? Can I interpret your answer to mean:

Yes, the property set functions are called before loadobj, and you can use these to accept and convert old property data. The NOW transient property will STILL CALL THE SET METHOD because there is saved data for it: the overall aim of the loading process is to get all the saved data successsfully sent into your new object.

Thanks again for your help.