Class using static method causes clear warning

I am implementing a class (ClassA) that use a static method for the initialization of a help variable, needed at Construction. An instance of ClassA is then a property of another class, ClassB. This seems to provoke the following MATLAB warning:

"Warning: Objects of 'ClassA' class exist. Cannot clear this class or any of its superclasses."

The reason I use the static help method is that ClassA in its turn has a property (Property1) that is an Array of object of a third class, ClassC. I cannot seem to instantiate a 1-by-n ClassC at Construction of ClassA, but must instead separately construct the 1-by-n ClassC and return it from the static function in the definition of Property1.

The same thing happens when I create the variable used to initialize ClassA.Property1 using a "normal" function implemented as a utility external to ClassA. Construction and execution of all of this runs fine. It's just that I have the habit of doing >> clear all; close all; clear classes; between executions to make sure that I get a fresh start including all the changes in each run.

When I delete all uses of static funcions or external helper functions, the problem dissappears.

In the MATLAB documentation there is some brief mentioning of this error, but I cannot find anything about it explicitly related to class Construction using static methods.

[Guillaume]

Possibly you have some circular reference? I'm not sure how matlab copes with that.

Newer versions (R2014a and up) are much better at coping with changes to classes, so that you don't have to clear them anymore.

I personally dislike any code that starts with clear all; close all;, etc. Don't mess up with my workspace, do your stuff in your own workspace (i.e. use functions).

While there are legitimate reason to have static methods (class factories for example), I don't understand yours. Why can't you construct the C class in class A constructor? Can you show a minimal example of the problem?

[Håkan Lundgren]

The reason I nuke the workspace between runs is that by experience, I know it can happen that Changes to a class between test runs during development may otherwise not have an impect on class behaviour. Right or wrong, I am slightly alarmed at not being able to do a clear classes at the prompt without the aforemention warning showing up.

If I'm not successful in either deeming the warning not being a factor in later compilation, or solving the problem altogether, I'll take the time to post some code here.

Yes, why can't I construct ClassC in the ClassA constructor? I can, there are no warnings directly associated with that. It seems though from experimenting, that when a delete all class instantiation in property definition blocks, the warning does not occur.

[Guillaume]

In 2013b, you indeed need to clear classes (but only that) whenever you make edit to the class definition. As of 2014a, this is no longer necessary.

If you do get the warning and it is about one of your class, then in all likelihood the changes to your class have not been picked up. So you do have to worry about it.

I did happen the warning when I was writing classes in 2013b and prior. I don't think it's particularly to do with static methods. Most likely, it's the way references to other classes are being held.

Answer 1

[Titus Edelhofer]

Hi Hakan,

instead of a static method you could use a constant property. BTW, what version of MATLAB do you use? I remember those problems with not being able to clear classes was in previous versions of MATLAB but far less often in more recent versions ...

Titus

[Håkan Lundgren]

I use MATLAB Version: 8.2.0.701 (R2013b).

I am not sure I understand fully what You mean, though. If use a constant property I cannot change that property during runtime. Property1 in my above example is a state container for the process my system performs.

...or do You mean that the constant property can be used to initialize the actual Property1, which I use and update in runtime? In that case, am I not still stuck with the static initialization method to create the constant property?

Maybe this warning isn't such a big deal after all, but I don't feel good about sticking my head in the sand about it. It somehow pertains to memory management, and I intend to use MATLAB Compiler to create a standalone version of my application. In the light of that, I won't sleep well at night knowing that there was some memory issue during development...

Answer 2

[Håkan Lundgren]

Hi everybody,

I think I've solved it now. First off, big thanks to Titus and Guillaume who took the time and the effort to comment. Your remarks certainly led me in the right direction.

The problem was associated with the way i defined ClassB and classA in their respective classdef blocks. In the properties block I assigned default values, using my static method to instantiate members that are objects of other classes. Furthermore, I also implemented constructors that accepted initialization arguments to set initial property values from outside. Again, I used the static method.

I haven't penetrated exactly what this way of defining my class led to, but somehow multiple instances of the contained classes were associated with the scope of the ClassA and ClassB instances, and that became problematic when clearing them.

Once I deleted all default value declarations from the properties block in the classdef statement for ClassA and ClassB, the warning does not occur.

I guess another lesson here is that once You've defined a constructor accepting input arguments, it is always executed - even when the constructor is called with no arguments. In my haste to move forward, I didn't let go of my notion that the properties block in classdef is always "master" - which it really isn't.

[Titus Edelhofer]

Hi Hakan,

yes, that's right. When you have a constructor you always have to implement "default constructor", i.e., the constructor without arguments. Take the following example:

c(2) = myobj(input1, input2);

In this case MATLAB will call the constructor without input arguments to create the variable c(1).

Titus