OOP in MatLab -- assigning values to properties?

I am trying to understand how MatLab does OOP in R2013b, so I got started with a simple test class, but it doesn't seem to behave as desired. The test class has 2 properties, A and B, which I keep at default scope (which I believe is public). I used the following class definition, with default values:
classdef classtest
properties
A = 0;
B = uint64(5);
end
methods
function changeA(obj, newA)
obj.A = newA;
end
function changeB(obj, newB)
obj.B = newB;
end
end
end
Then I run the following code, with outputs shown:
>> a=classtest;
>> a
a =
classtest with properties:
A: 0
B: 5
>> a.changeA(128);
>> a.changeB(256);
>> a
a =
classtest with properties:
A: 0
B: 5
>>
The values of A and B have not updated based on the method executed, but are instead still their default values.
What am I doing wrong?

 Accepted Answer

Your class is not a handle class but rather a value class. Thus when you run:
a.changeB(256);
A new variable ans in your workspace will exist with the change. If you want to update the value in this a and keep it as a value class, assign the output back to a:
a = changeA(a,128)
Or change your class to a handle class. It really depends on what you plan to do with this class as to whether you want it as a handle or value class:
classdef classtest < handle

3 Comments

Thank you! Extending handle worked as desired. I want to track values similarly to this, so it looks like a handle class is exactly what I want. I guess my C++ background makes me think every class should behave like a "handle" class, but I assume there are times when you don't want that behavior. Regardless, it now works by simply extending handle, as I would expect.
My overall goal with the actual class I am creating is to track the value of a memory location, so I can pass it back and forth to mex and don't lose track of the data location in memory. I prefer using OOP so I can use the delete(obj) destructor method to ensure the memory gets freed even if the programmer is "lazy" (or just forgets to call it).
That sounds about right!
The only time I use value classes is when I want them to behave, well I guess, as values. A simple (e.g. double or uint8) matrix is a value class because when you pass it into the function, the function cannot change it. So when making a class that will behave like a matrix, I would use a value class.
For the OP's definition of changeA, a = changeA(a,128) gives an error. It is worth pointing out that the handle/value class issue is flagged by mlint.
@Sam As for value and handle classes, I think the polynomial class example in the documentation highlights a good use case of a value class.

Sign in to comment.

More Answers (0)

Categories

Products

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!