i have this superClass
classdef SysSignal<handle
%SIGNALP Summary of this class goes here
% Detailed explanation goes here
properties (SetAccess = public, GetAccess = public )
SetOfSignal = containers.Map('KeyType','char', 'ValueType', 'any')
end
methods
%constructor
function sys=SysSignal()
end
function sys=adds(sys,varargin)
%convert form cell to signalup
for n=1:length(varargin)
signal=varargin{1,n};
if isempty(signal.name)
continue
else
%add to the map
sys.SetOfSignal(signal.name)= signal;
end
end
end
and that child class
classdef Signalp<SysSignal
%SIGNALP Summary of this class goes here
% Detailed explanation goes here
properties
name
lineNo
color='red'
sumrole
end
properties (SetAccess=private,GetAccess=public)
arrPrice
LineLength
LineProportion
end
methods
%constructor
function sig=Signalp(varargin)
end
end
end
now i want to change the properties like this:
sys=SysSignal;
s=Signalp;
s.name='dd';
sys.adds(s)
sys.SetOfSignal('dd').sumrole='hello'
but i get that error :
??? Error using ==> subsasgn
Only one level of indexing is supported by a containers.Map.
how can i change the values from the superClass?
The answer is to seperate sys.SetOfSignal('dd').sumrole='hello' into two statements:
dd = sys.SetOfSignal('dd');
dd.sumrole='hello'
That is because sys.SetOfSignal('dd').sumrole doesn't do what you'd intuitively think it does. Indeed the containers.Map class overloads the subscripted reference and subscripted assignment operators. In essence they 'intercepts' the (), {} and . operators at the same time (ie .sumrole is 'sent' to the map.Containers object - instead of your object!). In my opinion that's a really weird design decision but we must live with it!
Have a look at these links for more info:
subsref, subsasgn
gregswiss's answer is correct, except that accessing the containers map creates a copy, so you finish by replacing the old value with the new modified one
dd = sys.SetOfSignal('dd');
dd.sumrole='hello'
sys.SetOfSignal('dd') = dd;
Related
I like the OO programming style that matlabs App Designer uses (or at least the way I'm using it). Now I'm wondering if I can use the same style in my "normal" matlab class.
What I have now:
classdef myClass
properties
myVar;
end
methods
function Main(obj)
obj.myVar = "a";
obj = DoSomething(obj);
disp(obj.myVar) % outputs "c"
end
function obj = DoSomething(obj)
if(obj.myVar == "a")
obj.myVar="c";
else
obj.myVar = "b";
end
end
end
end
Which can be called externally using:
myClassInst = myClass;
myClassInst.Main()
I would like to get rid of all the "obj = " in the classdef, as is possible in App Designer. So something that would look like this:
classdef myClass
properties
myVar;
end
methods
function Main(obj)
obj.myVar = "a";
DoSomething(obj); % Just call the function without "obj = "
disp(obj.myVar) % outputs "a" because I didn't overwrite obj
end
function DoSomething(obj)
if(obj.myVar == "a")
obj.myVar="c";
else
obj.myVar = "b";
end
end
end
end
The equivalent of this seems to work in App Designer. So it appears you can modify variables in a class (instance?) in App Designer, while also being able to access the modified variable without explicitly overwriting your old class instance.
I noticed App Designer has all methods an properties set to (Access = private), though I'm not sure that has anything to do with it. Of course if I set everything to private, then I can't access the Main() method from outside anymore.
So my question is, how can I program in "normal" matlab, the same way as is possible in App Designer?
EDIT:
The following works in App Designer (I left out the methods/properties for the GUI elements):
classdef tmp < matlab.apps.AppBase
properties (Access = private)
myVar; % Description
end
methods (Access = private)
function doSomething(app)
if app.myVar == "a"
app.myVar = "c";
else
app.myVar = "b";
end
end
end
% Callbacks that handle component events
methods (Access = private)
% Code that executes after component creation
function startupFcn(app)
app.myVar = "a";
doSomething(app);
disp(app.myVar); % outputs "c"
end
end
end
You definitely can! All you have to do is inherit from the handle class, as opposed to a value class which is the default for matlab. You can also define private and public methods as in other languages.
The only thing you have to do is:
classdef myclass < handle % this is how you inherit from base class
properties
public_property
end
properties (Access=private)
private_property
end
methods
function obj = myclass() % class constructor
...
end
function public_function()
...
end
end
methods (Access=private)
function private_function()
...
end
end
end
Now every time you pass an object of this class to a function, you are not passing it by value, you are passing by reference (as you might be used to from python) and modifying it's properties modifies them also in the original object.
You need to inherit (< at the top of the class) from a handle class
classdef myClass < handle
properties
var
end
methods
function obj = myClass( varargin )
% Constructor function, called automatically when object is created
end
function someFunction( obj )
obj.randomizeVar(); % Equivalent to randomizeVar( obj );
end
function randomizeVar( obj )
obj.var = rand();
end
end
end
See the documentation for the difference between a "handle" and "value" class:
A value class constructor returns an object that is associated with the variable to which it is assigned. If you reassign this variable, MATLAB® creates an independent copy of the original object. If you pass this variable to a function to modify it, the function must return the modified object as an output argument. For information on value-class behavior, see Avoid Unnecessary Copies of Data.
A handle class constructor returns a handle object that is a reference to the object created. You can assign the handle object to multiple variables or pass it to functions without causing MATLAB to make a copy of the original object. A function that modifies a handle object passed as an input argument does not need to return the object.
Moreover, if you edit matlab.apps.AppBase, the class which you app designer code inherits, you can see that the first line is
classdef AppBase < handle
So you are literally doing the same thing, without the AppBase middle-man.
Ok, so I have a parent class MOM with a bunch of properties with the SetAccess attribute set to protected. It has a special static method setProperty for setting its properties:
classdef MOM < handle
properties (SetAccess = 'protected')
age;
occupation;
num_kids;
MOMmusthaves ={'age','occupation','num_kids'};
end
methods
function obj = MOM(varargin)
if iscell(varargin{1,1})
varargin =varargin{1,1};
end
inputstrings=varargin(cellfun(#isstring,varargin)); % get strings out of the inputs
if(isempty(setxor(intersect(inputstrings,obj.MOMmusthaves),obj.MOMmusthaves)))
% if all proper inputs are entered, initialize your object
for pp =1:length(obj.MOMmusthaves)
obj.setProperty(obj,varargin,obj.MOMmusthaves{pp});%find each input in the vararagins, and set it
end
else
display('Hey! These inputs are wrong. type help MOM for an example. Make sure you inlcude inputs for all of the following:'); obj.MOMmusthaves
return;
end
end
end
methods (Static)
function setProperty(obj,varargs,xx)
eval(sprintf('obj.%s = varargs{find(strcmp(''%s'',varargs))+1};',xx,xx));
end
end
end
Then I have a child object KID, which has a couple more properties, also SetAccess protected. When I try to use MOM's static method to set a KID property inside the KID's constructor I get an error :(
The error says:
You cannot set the read-only property 'allowance' of KID.
Basically, it seems like KID doesn't think that it can use MOM's static method as its own (so didn't inherit it properly).
MY QUESTION IS:
Is there any way I can make the static method be recycled and usable to KID for its own protected properties?
JUST FYI, here's something like the KID code;
classdef KID < MOM
properties (SetAccess = 'protected')
gender;
allowance;
favoritecandy;
KIDmusthaves ={'gender','allowance','favoritecandy'};
end
methods
function obj = KID(varargin)
obj = obj#MOM(varargin(:)); % Special construct for instantiating the superclass
inputstrings=varargin(cellfun(#isstring,varargin)); % get strings out of the inputs.
if(isempty(setxor(intersect(inputstrings,obj.KIDmusthaves),obj.KIDmusthaves)))
% if all proper inputs are entered, initialize your object
for pp =1:length(obj.KIDmusthaves)
%find each input in the vararagins, and set it
obj.setProperty(obj,varargin,obj.KIDmusthaves{pp});
end
else
display('please use correct input format. Make sure you include inputs for all of the following:');
obj.KIDmusthaves
return;
end
end
end
end
I'm not really sure what the exact source of the error is; although, I think it may be due to the mutation of the handle object being hidden by the eval.
Regardless, if I understand the intended usage of setProperty, I think it may be easiest to write the function in a non-static form using dot notation (similar to dynamic field names with structs):
methods
function [] = setProperty(obj,musthaves,varargin)
keys = varargin(1:2:end);
values = varargin(2:2:end);
for pp =1:length(keys)
key = keys{k};
if any(strcmp(musthaves,key))
obj.(key) = values{pp};
end
end
end
end
where musthaves is any cell array of property strings
You could also have musthaves be a string that indicates the obj property holding the property list:
methods
function [] = setProperty(obj,musthaves,varargin)
keys = varargin(1:2:end);
values = varargin(2:2:end);
for pp =1:length(keys)
key = keys{k};
if any(strcmp(obj.(musthaves),key))
obj.(key) = values{pp};
end
end
end
end
First of all, I belive I should say that I am a newbie on OOP in Matlab, but quite experenced with other languages like C++. So this question may sound like so easy to you but I somehow could not find an explanation to my problem.
Suppose that I have two classes, where the former one is an Abstract class and the latter one is a derived class which is derived from the abstract base class.
You can see an example below.
classdef (Abstract) queue < handle
properties
queue_array = [];
read_index =1;
end
methods
function insert_to_queue (obj, queue_element)
obj.queue_array = [obj.queue_array, queue_element];
end
function clean_queue (obj)
obj.queue_array = [];
obj.read_index = 1;
end
end
end
classdef fifo_queue < queue
properties
end
methods
function get_next_from_queue (obj)
...
end
end
end
Here as you can see, I put the common functions of all the derived classes to the base class for the purpose of code reuse.
However when I try a scrpt like below
f_que = fifo_queue;
f_que.instert_to_queue(some_data); % OK
f_que.clear_queue(); % Error
I got an error like;
No appropriate method, property, or field print for class fifo_queue
Do you have any idea of why I face with this type of behaviour on MATLAB?
Thanks
I come from a Java background. I am having issues with classes in Matlab particularly getters and setters. getting a message saying conflict between handle and value class I'm a little lost with what to do so any help for lack of a better word will be helpful.
classdef Person
properties(Access = private)
name;
age;
end
methods
% class constructor
function obj = Person(age,name)
obj.age = age;
obj.name = name;
end
%getters
function name = get.name(obj)
end
function age = get.age(obj)
end
%setters
function value = set.name(obj,name)
end
function value = set.age(obj,age)
end
end
end
Implementation
Since your class is currently a subclass of the default Value class, your setters need to return the modified object:
function obj = set.name(obj,name)
end
function obj = set.age(obj,age)
end
From the documention: "If you pass [a value class] to a function, the function must return the modified object." And in particular: "In value classes, methods ... that modify the object must return a modified object to copy over the existing object variable".
Handle classes (classdef Person < handle) do not need to return the modified object (like returning void):
function [] = set.name(obj,name)
end
function [] = set.age(obj,age)
end
Value vs. Handle
Going a bit deeper, the difference between a Value class and a Handle class lies mostly in assignment:
Assigning a Value class instance to a variable creates a copy of that class.
Assigning a Handle class instance to a variable create a reference (alias) to that instance.
The Mathworks has a good rundown on this topic.
To paraphrase their illustration, the behavior of a Value class is
% p is an instance of Polynomial
p = Polynomial();
% p2 is also an instance of Polynomial with p's state at assignment
p2 = p;
and of a Handle class is
% db is an instance of Database
db = Database();
% db2 is a reference to the db instance
db2 = db;
Quick'n Dirty from the Java perspective:
- "handle" classes are what your mind is set to. proper object instances with pointers to them. use them.
- "value" classes are always returning a full clone of whatever object (which has been modified by what you just did, e.g. setting a name).
the reason they have both in Matlab is that in Matlab you would expect the "value" behaviour natively. Imagine you have a matrix A = [1 2; 3 4], then assign that via B = A. if you now set B(1) = -1 you'd hope that A(1) is still 1, right? this is because matlab keeps track of "copies" and truly creates them as you modify different variables initially set to the same matrix. in OOP you'd have A(1)=-1 now as everythings an object reference.
furthermore, "native" matlab routines dont have a "this/self/me" variable that contains the instance reference to access from within functions. instead, the convention is that the class instance will be prepended to the function's argument list.
so for a function call myclass.mymethod(arg1,arg1), the declaration must be
function mymethod(this, arg1, arg2)
% Note that the name you choose for "this" is arbitrary!
end
mind you, this is the java-perspective (and also my favourite one), the above function call is equivalent to mymethod(myclass,arg1,arg1). this is more native to matlab-style, but somehow makes it harder to see you're calling an objects method.
now, regarding setters/getters: for handle classes, everything feels java-ish now:
classdef MyClass < handle
properties
MyProp;
end
methods
function set.MyProp(this, value) %Note: setMyProp is also valid!
... % do checks etc, trigger calls,
this.MyProp = value;
end
function value = get.MyProp(this)
... % notify, update, triggers etc
value = this.MyProp;
end
end
Of course it goes without saying that you dont need to define a getter if you just want to return the value, i.e. myclassinstance.MyProp will work without any just as well.
Finally, getters/setters for value classes are something that [never encountered me/i never needed] in my 7 years of matlab oop, so my advise would be to go with handle classes and enjoy happy matlab coding :-)
otherwise, the above explanation & official matlab docs is doing the job for value class getter/setters.
I'd like to customize the display of an enumeration class using matlab.mixin.CustomDisplay.
If I have a regular (non-enumeration) class such as the following:
classdef test < handle & matlab.mixin.CustomDisplay
properties
value
end
methods
function obj = test(value)
obj.value = value;
end
end
methods (Access = protected)
function displayScalarObject(obj)
disp(['hello ', num2str(obj.value)])
end
end
end
then everything works fine - for example,
>> a = test(1)
a =
hello 1
But if I have an enumeration class such as the following (note the addition of the enumeration block):
classdef test < handle & matlab.mixin.CustomDisplay
properties
value
end
methods
function obj = test(value)
obj.value = value;
end
end
methods (Access = protected)
function displayScalarObject(obj)
disp(['hello ', num2str(obj.value)])
end
end
enumeration
enum1(1)
end
end
then the display is not customized - for example,
>> a = test.enum1
a =
enum1
Using the debugger, I can see that my displayScalarObject method is never called. Implementing other methods of matlab.mixin.CustomDisplay such as displayNonScalarObject and so on doesn't seem to help - these never get called either.
What's going on? Do disp and display work differently for enumeration classes, in such a way that anything that's overridden by matlab.mixin.CustomDisplay just gets ignored?
Is there a way to get a customized display with matlab.mixin.CustomDisplay, but using an enumeration class?
PS I am able to directly overload disp and/or display on an enumeration class that does not inherit from matlab.mixin.CustomDisplay, and this works fine. But I'm looking to use matlab.mixin.CustomDisplay if possible.
I'll answer my own question in case anyone else is interested.
The question was asked with reference to MATLAB R2014a. In R2014b, an additional note has been added to the documentation for matlab.mixin.CustomDisplay, making it explicit that it is not possible to use matlab.mixin.CustomDisplay to derive a custom display for enumeration classes, and suggesting that the best approach is to overload disp.