I am having some trouble with matlab. I am working with b-splines. Sometimes I want to work with the actual spline, while other times I only want to use the so-called basis functions. Without diving into the theory of b-splines, the practical difference is that the when I want to work with the b-spline, I need an extra method and property. I want this property to be initialized by passing it in the constructor.
What I have so far (with most irrelevant methods and properties removed) hopefully roughly demonstrates the behavior that I want:
bsplinespace.m:
classdef bsplinespace < handle
properties
p % polynomial degree
end
methods
function result = bsplinespace(p)
result.p = p;
end
end
end
bspline.m:
classdef bspline < bsplinespace
properties
controlpoints
end
methods
function result = bspline(p, controlpoints)
result.controlpoints = controlpoints;
end
function result = getp(this)
result = this.p;
end
end
end
However, in this scenario the bspline constructor calls the bsplinespace constructor without passing any arguments, causing it to crash:
Not enough input arguments.
Error in bsplinespace (line 8)
result.p = p;
Error in bspline (line 7)
function result = bspline(p, controlpoints)
To be more explicit, what I want is:
One class bsplinespace, which has a constructor which accepts one parameter p
A class bspline, which is the same, but has an extra property and method
Is there an elegant way to implement this?
In your constructor method for bspline, you need to explicitly call the superclass constructor with input argument p:
function result = bspline(p, controlpoints)
result#bsplinespace(p)
result.controlpoints = controlpoints;
end
Otherwise MATLAB will call the superclass constructor with zero input arguments, and you'll get the error you're seeing.
It's a perfectly sensible design, and allows you to control the details of how arguments to the subclass constructor are passed through to the superclass constructor (or not, if you'd like to provide default arguments instead).
Related
Constant properties are static properties(belongs to classes, not instances) in Matlab, like many other OOP languages. And natural way to access them is ClassName.PropName as in Matlab documentation.
However, I couldn't find a way to do ClassName.PropName from a superclass, in a scenario like this:
classdef (Abstract) Superclass < handle
properties(Dependent)
dependentProperty
end
properties (Abstract, Constant)
constantProperty
end
methods
function result = get.dependentProperty(obj)
c = class(obj); % Here I have to get class of obj
result = length(c.constantProperty); % to use here as `ClassName.PropName`
end
end
end
classdef Subclass < Superclass
properties (Constant)
constantProperty = [cellstr('a'); cellstr('b')];
end
end
so that following commands results following outputs this:(expected output)
>> subclassInstance = Subclass()
subclassInstance =
Subclass with properties:
constantProperty: {2×1 cell}
dependentProperty: 2
>> subclassInstance.dependentProperty
ans =
2
>>
But instead, I get following this:(actual output)
>> subclassInstance = Subclass()
subclassInstance =
Subclass with properties:
constantProperty: {2×1 cell}
>> subclassInstance.dependentProperty
Struct contents reference from a non-struct array object.
Error in Superclass/get.dependentProperty (line 13)
result = length(c.constantProperty);
>>
Also tried: c = metaclass(obj) which gives "No appropriate method, property, or field 'constantProperty' for
class 'meta.class'."
Question: Is there any way to obtain class of an object from superclass, to be able write a statement like ClassName.PropName?
EDIT:
I know I can reach from object reference like this:
function result = get.dependentProperty(obj)
result = length(obj.constantProperty);
end
But this is not what I want as it makes reader to think constantProperty is an instance property. Also this is not documented in Matlab, instead documentation says ClassName.PropName and this makes me think that there must be a way.
The right way to do this in matlab is through the instance, as per the part of my previous answer you have now incorporated in your question. This is because matlab's object-orientation model is "instance" based.
The constant property is an instance property; it just happens to be the same (i.e. constant) in all instances. Presumably, this is why it's called "constant", not "static": it does not refer to a single static item in memory, like in c; instead every instance is instantiated with that same constant value.
You gain nothing by going out of your way to call it via a "class reference" (no such thing exists btw; unlike python and julia, class prototypes are not objects that can be referred to, nor do they have a type themselves).
However, if you insist, there does happen to be a way to do this using metaclasses, since a constant property set from within the constructor will have a default value named in its metaclass profile
subclassInstance = Subclass();
m = metaclass(subclassInstance);
mp = findobj (m.PropertyList, 'Name', 'constantProperty');
mp.DefaultValue
Also, to address why class(subclassInstance).constantProperty doesn't work, this is simply because the result of class(subclassInstance) is a string (whose value happens to be the classname), not a "reference" to a class (like I said, such a thing doesn't exist in matlab).
However, if you wanted to, obviously you could use such a classname string within an eval statement, to evaluate it as if you were typing it directly in the terminal to access the constant property. So this is another way of achieving what you're after:
eval([class(subclassInstance) '.constantProperty'])
but in theory eval statements should generally be avoided unless there's no alternative.
Short note:
in Java this is possible by this.getClass()
In java this is called reflection, and it's java's own mechanism for 'inspecting' objects. When you do something like myObject.getClass(), what you're returning is still not a "reference to a class prototype". It's an instance of type Class. I.e. even in java, you can't do myObject.getClass().aStaticProperty. But you can use the getFields method provided by the Class class to obtain Field objects, and inspect their value with respect to specific object instances; for static fields, this instance simply becomes the null object.
I'm learning about MATLAB classes they certainly seem different to what I'm used to. Below is an example class I'm using.
I initialise my class with the line below,
myClass = ClassTest(3);
This is fine. The issue I have is calling the RunMain function.
First call
myClass.RunMain(myClass)
I get the error message too many inputs.
Second call
myClass.RunMain(myClass, anything)
This call works. However, I find it strange I need to supply a second parameter which is never used - just seem messy. Sure I'm missing something here.
classdef ClassTest < handle
properties
myNum;
myDate = datenum(date);
end
methods
function ct = ClassTest(someNum)
ct.myNum = someNum;
end
% this function does not work when called
%function RunMain(obj)
% obj.myNum = obj.myNum * 2;
% disp(obj.myNum);
%end
% this works
function RunMain(obj, anything)
obj.myNum = obj.myNum * 2;
disp(obj.myNum);
end
end
Update
I can see when I debug that the anything parameter is exactly the same as obj even obj.myNum has changed value.
Correct syntax for calling a method where myClass is an object of the class defining the method RunMain is:
In case of function RunMain(obj) it is one of these:
myClass.RunMain()
RunMain(myClass)
In case of function RunMain(obj, anything) it is one of these:
myClass.RunMain(anything)
RunMain(myClass, anything)
You can find more details regarding syntax here:
http://de.mathworks.com/help/matlab/matlab_oop/ordinary-methods.html
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.
My mate is trying to do this on matlab (Please excuse the terminology. I am not super sure with matlab.)
He is entering two structures which are polynomials into a class as parameters in methods but it will only accept doubles for some reason. hOW do you fix this?
classdef dostuff
properties
polyn %not really sure what this does
end
methods
function r = plus(struct1, struct2)
r = dostuff(addthem(struct1,struct2)); %adds the two polynomials
end
end
end
The error is Undefined function 'dostuff' for input arguments of type 'struct'.
How do you get the class to accept structures (polynomials) as parameters?
The class dostuff does not have a constructor that will accept a struct. So the call to
dostuff(addthem(struct1,struct2))
is trying to call a constructor that doesn't exist. You would need a constructor like
methods
function obj = dostuff(mystruct)
obj = <...>
end
end
I have defined an abstract base class measurementHandler < handle which defines the interface for all inherited classes. Two subclasses of this class are a < measurementHandler and b < measurementHandler.
I now have a function which should return a handle to an instance of either of these subclasses (depending on the function arguments) to it's caller. Consider something like this:
function returnValue = foobar(index)
if index == 0
returnValue = a();
else
returnValue = b();
end
end
This function is enclosed in a MATLAB Function block in Simulink (2013a). When I try to simulate the system, I get the following error:
Type name mismatch (a ~= b).
Can anybody suggest a workaround for this which still allows me to take advantage of OOP & inheritance when using Simulink?
This kind of pattern is possible in MATLAB Function block only if the "if" condition can be evaluated at compile time. The types cannot be switched at run-time. Can you make the index value a constant at the call site?
The main reason to use this pattern was to iterate over a measurementHandler Array, while these all can have custom implementations. I was able to do this by unrolling the loop with the coder.unroll directive. Example for the enclosing MTALAB Function block:
function result = handleAllTheMeasurements(someInputs)
%#codegen
for index = coder.unroll(1:2)
measurementHandler = foobar(index);
measurementHandler.handleMeasurement(someInputs);
end
result = something;
end
This way, the for loop gets unrolled at compile time and the return type of the function is well defined for each separate call.