I wish to add a method called nansubset to the table class. Essentially it allows you to call T(r,c) where r and c are real positive integer vectors possibly containing NaN's.
Stubbed code for nansubset.m could be:
function T = nansubset(T, r, c)
T = T(r,c);
end
I am following the instructions here, which detail how to add a new method to the cell class. Basically, in a folder on my Matlab path, I create a folder called #table, and within this folder, create a file called nansubset.m.
I am getting the following problems:
>> tmpT = table(); nansubset(tmpT, 1, 1)
Undefined function 'nansubset' for input arguments of type 'table'.
and
>> doc #table/nansubset
Your search - #table/nansubset - did not match any documents.
However:
edit nansubset
and
edit #table/nansubset
both open the method file in my editor.
Further, I followed the instructions in the above link to add the plus method to the cell class and find that it works perfectly.
Can someone please explain to me how I can add this additional method to the table class?
With the release of Matlab R2012b (version 8), the class folder behavior changed (emphasis is mine):
In MATLAB Versions 5 through 7, class folders do not shadow other class folders having the same name, but residing in later path folders. Instead, the class the combination of methods from all class folders having the same name define the class. This is no longer true.
For backward compatibility, classes defined in class folders always take precedence over functions and scripts having the same name, even those that come before them on the path.
The combination of the two bold statements explains the behavior:
cell is a built-in Matlab function that predates the new OOP rules that returns an instance of its class. And before R2012b, adding methods to a class folder called #cell added the methods to the object returned from the cell function (which isn't defined with a classdef nor a class folder); this ability was retained for compatibility with legacy user code.
table was added after R2012b, is defined via a class folder, and is Sealed. Since it is Sealed, it cannot be subclassed. And with the new rules, any #table folder without an associated classdef file will not register as a class folder nor will its methods be composed into the existing class unless it is part of the legacy system (like cell).
I can see three workarounds listed in the order I think is best:
Have a function on the Matlab path, just like the one you have, and always call the "method" using function notation instead of dot notation. If you need more "methods" group them in a folder or package (if good namespacing is desired) on the path. Since table is a value class, this option doesn't seem bad.
Create a wrapper class like the one below. It is cumbersome but automatically encapsulates the additional functions.
classdef MyTable < handle
properties
tab;
end
methods
function mytab = MyTable(varargin)
mytab.tab = table(varargin{:});
end
function tabnan = nansubset(mytab,r,c)
tabnan = mytab.tab(r,c);
end
end
end
Create a local copy of [matlabroot,'\toolbox\matlab\datatypes\#table\*'] and add the methods directly. I can't think of any huge drawbacks to this per se, but it feels weird copying internals like this.
Related
I'm working on rewriting an old MATLAB package. As part of that rewrite I'm updating two classes (lets call them old_class1 and old_class2) defined using the class() function to classes defined with classdef.
The definition of old_class1 contains the line superiorto('old_class2'). This function is not allowed in a constructor defined with classdef, but I am unable to find any equivalent. How do I create functionality equivalent to superiorto() in a class defined with classdef?
superiorto is no longer available in MATLAB, but I was able to find a copy of old documentation that indicates it was used to determine which object's method was called when multiple different classes were given as function arguments. For example, given obj1=class1() and obj2=class2(), with the class1 constructor containing superiorto('class2'), would cause function(obj1,obj2) to callclass1.function, rather thanclass2.function`.
With modern classdef functionality, the same can be accomplished by setting the InferiorClasses property:
classdef (InferiorClasses = {?class2}) class1
I tried to change an attribute value of a class by invoking one of its member function:
p1 = tank();
p1.checkOri(p1);
And in the class definition, I have that static method:
classdef tank
properties
value
...
end
methods
...
methods (Static)
function obj = checkOri(obj)
if (CONDITION) %the thing I want it to do
obj.value = EXPRESSION;
...
Yet this checkOri method is not working. But if I write this method in the main file, or to say altering the value of p1-the instance of class tank-it works perfectly:
p1 = tank();
p1.checkOri(p1);
if (CONDITION) %the thing I want it to do
p1.value = EXPRESSION;
It works perfectly.
I wonder what caused this. From my experience with other programming languages, invoking method should have worked, is it because of some tricks with Matlab syntax or static method? How could I fix it so that this method would work?
So, as #Navan in the comment said, handle class could be a solution.
It appears Matlab has a similar parameter concept with Java and C++, arguments modified in a function/method only remains that modification inside the function/method.
For this class, I simply added < handle in the head of class definition and it worked:
classdef tank < handle
properties
...
But I am not sure if that is the only solution, there might be better ways to do this. So I'll leave that question open, you are more than welcomed to post your opinion:D
In MATLAB, the call
p1.checkOri();
is equivalent to
checkOri(p1);
In both cases, the class method checkOri is called for the class of object p1, passing p1 as first argument to the function by value.
Because p1 is passed by value, any changes made to it inside the function are not seen by the object in the calling workspace. Therefore, one typically does
p1 = checkOri(p1);
This way, the object that was passed by value and modified inside the function is passed back out and assigned to the variable that held the original object.
If the method is written as follows:
function obj = checkOri(obj)
%...
end
then MATLAB will optimize the above function call such that no copy of the object is actually made. Note that both in the function declaration and in the function call, the input and output variable is the same.
As already discovered by OP, the above does not hold for handle classes, classes that inherit from handle. These classes act as if they are always passed by reference, and any change made to them in any workspace will be reflected in all other copies in other workspaces.
Also assigning to a member variable does not follow the above, such that
p1.value = 0;
modifies object p1.
For more information on the difference between value classes and handle classes see this other question.
I have a classe derived from matlab.mixin.Copyable. Some of the properties have set methods. I want the setting of those properties to also update other properties so that the relationship between the parameters are consistent (a classic use of set methods).
Unfortunately, when I load a *.mat file [specifically using, say, x=load('file.mat')], setters are also used. There should be no need for that kind of automatic update of multiple parameters, since all the object's properties can be copied from the *.mat file and self-consistency is automatically maintained. Instead, using setters during load causes errors because the setter uses other properties that haven't yet been assigned to in the load process. I see this from error that occurs during the load, and from checking the properties that are needed by the setter.
Is there any way to force the load to do a simple replication of the property values contained the *.mat file? Some of the properties are complex objects themselves, so what's needed is a recursive copy-by-value during load. It seems rather inappropriate to use setters during a load, for the reasons above.
P.S. I say above that the setter uses another as-yet-unassigned property. Let's call this property p2. It also gets assigned to by a setter for 3rd property s1. It seemed odd, but s1 does have a value, while p2 does not. One possible reason is that p2 relies on other properties in addition to s1, and those might not have been assigned to when s1 is loaded (i.e., when the s1 setter is invoked). The whole problem stems from the fact that load occurs outside of the context and the order in which properties are assigned to during the execution of the code that created it. This is the key reason why (it seems to me that) load should not use setters. Otherwise, it seems to be incompatible with either copying or loading (I'm not sure which at the moment -- maybe both).
The process MATLAB uses to load objects is well documented. This page mentions, among many other things, that the set methods are called to prevent issues that happen when a class definition changes, and you try to load an object from that class from an old file.
There is also a page explaining how to modify the save and load process. This page describes the use of loadobj, defined as a static method to your class, to change how the object is constructed from the information in the file. loadobj is called when one of the set methods throws an error; but it is always called if saveobj returns a struct. That is, one solution to your problem is to have saveobj create a struct with all the data, and have loadobj reconstruct your object from that struct.
This other documentation page describes how to design your class to avoid property initialization order dependency -- which is the problem you describe having. The way to do this is to have all public properties be dependent properties, with the "actual" data properties being hidden and not interdependent. You might be able to construct your class this way, for example with a single data property (a cell array or struct), which would be loaded and saved in one go, and the public properties simply using a portion of this cell or struct in the set and get methods.
In my example, I have a class representing a certain set of data. Some of the data's properties are written to the class' properties, while the class' methods mostly perform tasks like reading the raw data from spreadsheets and doing some pre-calculations.
I was wondering if the following is according to the "pure doctrine" of OOP, and if not, if and how it could be syntactically improved.
Here is a very simple (untested) implementation of such a class.
classdef dataObjectTest < handle
properties
filename char
pathFilename char
rawData double
end
methods
function obj = setPathnameFromFilename(obj, filename)
%setPathnameFromFilename Determine full path- & filename from single filename
% filename: Name of the file containing the raw data, e.g., 'Test.xls'
obj.filename = filename;
intermed = dir(obj.filename);
obj.pathFilename = fullfile(intermed.folder, obj.filename);
end
function obj = loadRawDataFromSpreadsheet(obj)
% loadRawDataFromSpreadsheet Convert the raw data stored in a spreadsheet into a Matlab
% array, using the full path- & filename determined by setPathnameFromFilename
% rawData: Array contating the raw data
obj.rawData = xlsread(obj.pathFilename);
end
end
end
And here is how one would call this class from another program/script:
test = dataObjectTest;
test.setPathnameFromFilename('Test.xls');
test.loadRawDataFromSpreadsheet;
I am especially concerned about the third line. Since both input and output arguments of the method loadRawDataFromSpreadsheet are properties of the class, it is unnecessary to explicitly define them in the function header. On the other hand, this implementation seems somehow awkward to me and not in "spirit" of OOP, which is a lot about clearly defined interfaces between the user and the class.
So although my code works, I'm still wondering if this is "the right way" to do it or if could be significantly improved.
UPDATE: Admittedly, the choice of my methods' names may have been misleading, but this was not the point of the question. So let me try to clarify.
The first method takes the user-given string filename and returns pathFilename. But since this is also a property of the class, it is not visible from the function signature, i.e., the function should look like:
function pathFilename = setPathnameFromFilename(obj, filename)
But this doesn't work in Matlab. (The varName = part corresponds to return varName in other languages.)
The second method returns the array rawData, and since the input argument pathFilenameis, again, a property of the class, neither are visible in the method's signature.
So my concern was about having methods which actually have in- and output arguments, but do not reveal them through their signature.
It's basically fine, but I'd implement it like this:
classdef dataObjectTest < handle
properties
filename char
pathname char
rawData array
end
methods
function loadRawDataFromSpreadsheet(obj, filename)
obj.filename = filename;
obj.pathname = dataObjectTest.extractPathName(filename
obj.rawData = xlsread(obj.pathname);
end
end
methods (Static, Access = private)
function pathname = extractPathName(filename)
intermed = dir(filename);
pathname = fullfile(intermed.folder, filename);
end
end
end
Notes:
Since it's a handle object, you don't need obj as an output argument of the main method.
I've moved the extraction of the path to a private static method, as it's really a utility function (you could instead implement as an actual subfunction rather than a method).
I've renamed the main method to start with load rather than get, to make sure it isn't mistaken for a property get method.
I wouldn't worry too much about the "spirit of OOP" - instead, just make sure your code works, is well-organised, is testable, and maintainable.
It is just fine according to the "doctrine" of pure OOP for a method to have no in or out parameters apart from the object reference.
However, what you are doing doesn't conform to normal practice for method naming. A method with a name starting with get is normally a "getter". The primary purpose of a "getter" is to return some component of the class. Generally speaking, a "getter" should not modify the target object.
But you have two get... methods that 1) modify the target object and 2) don't return anything.
In my opinion:
the first one should be named setPathnameFromFilename or maybe just setFilename.
the second one should be named loadRawDataFromSpreadsheet or something like that.
On the other hand, this implementation seems somehow awkward to me and not in "spirit" of OOP, which is a lot about clearly defined interfaces between the user and the class.
I actually don't see that at all. Sure, the interface is not clearly defined, but that is largely because you have not documented the methods and because you have chosen (IMO) misleading / non-informative class and method names.
(Disclaimer: I am a Java programmer. However, the basic principles of OOP are largely the same for all OO languages.)
I defined a class in one of my many MATLAB packages. To my suprise, I could not access a constant property of my class without importing the class definition. Even if it is a method of the class itself. Like so:
classdef TestClass
properties( Constant )
c=0;
end
methods
function obj = TestClass()
end
function getC(obj)
import test.TestClass;
disp(TestClass.c);
end
end
end
I just want to check whether I am doing something wrong here or is this the correct way to use constants in MATLAB.
Since you have placed TestClass inside a package Matlab needs to know where to look to find the definition for this class, even if it's a reference from within the class or function. An alternate to the above code could be:
function getC(obj)
disp(test.TestClass.c);
end
Alternately, if within a class, constant values can be accessed from the object itself.
function getC(obj)
disp(obj.c);
end
If neither of these is working for you, you may need to refresh the classdef for TestClass from memory. This will cause matlab to reload the constant value, which is pulled into Matlab when it first parses the classdef file to determine the structure of the class. This can be done using clear classes, however a warning that it will also clear all other classes, variables, and any breakpoints you have set.
If you want to see if this is necessary you can view the metaclass object to determine what Matlab "thinks" your class structure should be. You can do this using the following.
mc = ?test.TestClass;
mc.PropertyList
You may need to index into the property list to find the specific property you are interested in, but the thing you are looking for are the following fields.
Name: 'c'
Constant: 1
DefaultValue: 0