Why can we save only top level vaiable names?

Hello,

classdef test
properties
var = 'test'
end
end

a = test;
a.var
= test

var = a.var;
save('var.mat','var');

This will save a class property as one would expect, but this

save('var.mat','a.var') 

will be an error, because its not a valid variable name.

Why is that?

[Michael Kainzbauer]

Imagine var to be an extremly huge structure. Making a copy only to save it seems ridiculous to me.

Answer 1

[Walter Roberson]

It has never been valid in MATLAB to request to directly save an individual field (structures) or property (objects) or cell (cell arrays) or array element . Everything that gets saved is by variable name at the top level, and a.var is not a valid top-level variable name.

[Michael Kainzbauer]

"It has never been valid..."

ok, so its not just me right now...

But my question remains, why not?

The only consequence is, that one must make a copy first. Which happens in my project a lot.

I generalized my question.

[Walter Roberson]

But my question remains, why not?

The field in .mat files is restricted to pure variable names, not to indexed names.

Now suppose you make a a 7x2 array of objects of class test. What should be saved if a.var is requested to be saved ? What should its type be marked as? If it is marked as "struct array" with name 'a.var' size 7x2, then how do you distinguish that from the case where a is a scalar struct with field var that is a 7 x 2 struct array? You would have to introduce a new datatype, so that inside the .mat file, a.var is marked as being some kind of collection.

The only way to do it short of re-writing the rules about how .mat files are stored internally, would be if MATLAB introduced a temporary variable that is marked as not being a regular variable, such as if it used _a_var since valid variable names cannot start with _ -- with the _a_var storing the object array. But then it would have to modify other interfaces in order to permit the user to specifically request to load that variable including using the version of load that returns a struct.

You might be thinking "why doesn't it just store as a.var" ? It is because if you have

a = a 7 x 2 array of objects with fields var and obj
save('var.mat', 'a.var');   %a.var in file would have to meta-refer to 7 x 2 array with field var
a = a 3 x 11 array of objects with fields var and obj
save('var.mat', '-append','a.obj');   %a.obj in file would have to meta-refer to 3 x 11 array with field obj

then when you ask to retrieve the a.var from the file it has to pull out a 7 x 2 array, and when you ask to retrieve the a.obj from the file it has to pull out a 3 x 11 array, and those are not compatable uses of the name a . MATLAB cannot merge them in the file to a single non-scalar array a with fields var and obj because the sizes are not compatible.

Remember, a.var pulled back has to be the struct expansion of the non-scalar object (or struct) a with field var -- it would have to be come the only case in MATLAB where a single variable name is an expansion by itself without invoking an operator to make it expand, because it is not the case that a.var involved a scalar struct a with field var that happens to be 7 x 2.

Anything stored individually in a .mat file has to be recallable individually. Ask to store by a name that designates a scalar expansion and the result pulled back has to designate a scalar expansion, and yet somehow be individually designatable.