There is a functions.js file located in src/lib/ and there is a function in it.
That file has been included into slug.json.
How could we call that function inside the controller?
In coffeescript each file is wrapped with an anonymous function to avoid leaking into global scope. If you want to leak into global scope on purpose, you need to put the function in "window":
window.check_pants = (size) ->
"No pants are too tight"
You can then call the function in the controller as "check_pants", that is to say that callers don't need to include "window".
Since "this" refers to window by default, you can use an "#" sign:
#check_slants = (size) ->
"Too slanted"
Related
I have set up a tiny test class with one member variable. I am trying to change this variable within a member function of the class.
I have named the class: "Test"
I've created a new folder: #Test where all methods are inside. The folder looks like this:
In Test.m (the constructor) there is the following code:
function obj = Test()
#member variable
mem.memory = [1,5,2,4,3];
obj = class (mem, "Test");
endfunction
Then I also have the "display" method:
function display(obj)
obj.memory
endfunction
And the method to change the member variable:
function change(obj)
obj.memory = [9,8,7,8,9];
endfunction
the last thing I have is the main script, here I'm creating a new object of the class Test, display it, change it, display it again. This file lies one folder above the #Test folder:
clc
clear all
c = Test();
display(c);
change(c);
display(c);
Here is the output of the program:
Like you can see, the values didn't change to 9 8 7 8 9. It feels like the variable is set to const, but also there comes no error, like: you can not change const variables...
I looked online for some examples, but only could find stange things...
It would be nice, if someone can link me a good tutorial about classes.
You need to change this to
function obj = change(obj)
obj.memory = [9,8,7,8,9];
and then call the method as
c = change(c);
In the MATLAB language, all function inputs are taken by value, not by reference (with the exception of handle classes). Thus, changing the copy of obj inside the function does not change the object in the caller workspace. The copy needs to be returned and assigned to the original variable.
MATLAB does optimize the syntax to not actually make any copies. I think Octave does the same, but am not sure.
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've tried searching for an explanation on this exact scenario but couldn't find anything. I have a module that looks like the following (simplified):
export default function(name) {
return map[name];
}
const map = {
'a': 'b',
'b': 'c'
};
Clearly the const definition above is hoisted but it should be undefined when being used in the function. I'm trying to find an exact explanation for why this function works when imported and used. Shouldn't a reference error be thrown? The only thing I can think of is that the entire module is loaded prior to when this function is called, but how exactly does that happen or where is this specific behavior explained? Any information would be really appreciated.
JS uses lexical scoping, meaning that a scope is defined as part of the nested structure of the code. Anything referencing the name of a variable anywhere in that scope can attempt to access the value. What the actual value is depends on when the value is initialized, which is a runtime property of the code.
When people talk about hoisting in JS generally it is not super clear which of these things they are describing. In JS, because scopes are lexically-based, the existence of a given variable is hoisted, in that it always exists within that scope.
The actual initialization of a variable in a scope depends on the way the variable is declared.
function foo(){} declarations have their initialization hoisted, so the variable foo will always be available in the body of the function, even if the declaration comes later. e.g.
foo();
function foo(){}
is perfectly valid valid.
var foo = 4; hoists initialization, but the value is initialized to undefined until the declaration has executed, e.g.
foo; // undefined
var foo = 4;
foo; // 4
let/const performs initialization only when executed, and attempts to access uninitialized variables will throw an exception.
foo; // would throw because it is not initialized yet
let foo = 4;
foo; // 4
So taking those together, the behavior of variables is only determined at runtime. For your code example, it depends on when the function is called. Since let foo = 4; only initialized foo when it runs, if the function were called first, it would fail, and if the function were called after, it would work.
function log(){
console.log(foo);
}
log(); // would throw because foo has not been initialized
let foo = 4;
log(); // would log 4
This behavior of delayed initialization for let and const is commonly referred to as the "temporal dead zone".
At the end of the day, as long as the variable has been initialized and has the value you care about by the time you access it, your code is fine. Whether you have access to the variable in the first place only depends on the nesting of your code.
The call can only be made (outside of this module) after the whole module you provided is executed (which means that map is already initialized by the time the function is called)
This observation is based on the fact that when you import a module, all of the code inside it will be executed.
To call the function, one would have to import the module you provided.
See Does ES6 module importing execute the code inside the imported file? for when code executes on import.
For example:
function s = slexpdatasetSLAP()
s = s#slexpdataset('slapCC','SLAP dataset for collective classification'); %slexpdataset is a class defined in another .m file
s.discription ='CC';
end
As I know, # is used as creating a function handle in MATLAB, but obviously that interpretation is not suitable in this context. So what does that at # mean?
This is the syntax for calling the constructor of the super-class
In general, for calling a method of the superclass, you'd use the syntax
outputs = methodName#superclassname(obj, input, arguments)
However, calling the constructor is a little different since you use the variable name for your object's instance in place of methodName in the example above
obj = obj#superclassname(input, arguments)
In your case, rather than obj, you're using s as the variable to refer to the class instance (since you define that as the output from your constructor), so you're essentially calling the constructor of slexpdataset and passing it the list of arguments shown.
Is it possible to view the handle class properties when debugging a matlab function block in simulink?
Currently I have a matlab function block which instantiates a class. In neither the function block or the class itself can I see the properties of the class during debug. My workspace is empty.
When I run who while debugging I only get variables inside the function scope and no persistent variables (in the function block) and no class properties (inside the class itself).
The only way to debug now is to store properties inside a local variable.
Viewing class information is not supported by MATLAB Function block when debugging. The only way is to assign property values to local variables. Documentation at http://www.mathworks.com/help/simulink/ug/how-working-with-matlab-classes-is-different-for-code-generation.html has a line "If you use classes in code in the MATLAB Function block, you cannot use the debugger to view class information.".
classdef foo < handle
methods
function o = my_fcn(obj, in)
my_prop = obj.my_prop;
o = in * my_prop;
end
end
end
In the above code for function my_fcn you can see in, o and my_prop. But not obj.