When I use multiple assignment operator such as a = b = c and b is a getter/setter, the setter is invoked perfectly but getter not; why?
Here's a simple example:
//define simple example class to describe the situation
export class GetterSetter
{
private m_sValue:string = '';
constructor ()
{
}
public get value (): string
{
return this.m_sValue;
}
private set value (val:string)
{
this.m_sValue = (val ?? '').trim();
}
public getValue1 (): string
{
let ret:string = this.value;
this.value = null!;
ret = this.value;
return ret;
}
public getValue2 (): string
{
let ret:string = this.value;
ret = this.value = null!;
return ret;
}
}
//invocation
const obj:GetterSetter = new GetterSetter();
const s1:string = obj.getValue1();
const s2:string = obj.getValue2();
getValue1() works as expected. getValue2() produces null. In getValue2() the setter is invoked twice as expected but the getter never invoked.
For getValue2() I expected the getter to be invoked for this line:
ret = this.value = null!;
but it was not. It happens both in debugger and in production.
The JavaScript assignment expression y = x evaluates to its right-hand side, so y = x can be thought of as just x. But it also has the effect of assigning the right-hand side to the variable/property on the left-hand side. So after y = x is done, x has been assigned to y. Note that nowhere in that description is y ever evaluated or read from; it is only written to. Code that only triggers when y is read from will not trigger.
In a compound statement like z = y = x, or the equivalent z = (y = x), first the inner assignment y = x happens, which assigns x to y and evaluates to x. Then the outer assignment happens, which assigns x to z (and also evaluates to x but that is simply discarded). Again, at no point is y (or z for that matter) ever read, so any code triggered by reading y will stay untriggered.
So there you go. z = y = x does not behave like "x is assigned to y and then y is assigned to z". Instead, it behaves like "x is assigned to both y and z".
Related
I've made a function "ADD" which modifies the value of a variable :
function ADD(xs, n)
{
var nom_variable = xs;
var XS = eval(xs);
nouvelle_valeur = eval(nom_variable + "=XS+n");
}
var x = 5 ;
ADD("x",5); // now x = 10
I would like that the first argument of the function ADD is x, not "x". Is this possible ?
I want my students to write algorithms in a way similar to natural language.
Thanks !
You can't pass x as if it were a reference, but you could construct a functional reference (or Lens) although you are still not passing x but a variable that is a reference of x.
var x = 5;
var xRef = {
get : function(){
return x;
},
set : function(val){
x = val;
}
}
function add(ref, n){
var oldVal = ref.get();
ref.set(oldVal+n);
}
add(xRef, 5);
console.log(x);
It's definitely not pretty though.
I've looked into it, and it seems as though ES6 doesn't have the ability to set properties of a class, and return that class?
class MyClass {
constructor() {
this.x = 0;
this.y = 0;
}
update(value) {
// logic
this.y = value;
return value;
}
}
var x = new MyClass();
console.log(x.update(1));
With the above, x will keep y as 0, even though setting y to 1. console.log will put out 1, but y is never actually updated. Calling x.y will result in 0.
I've also attempted returning the class, yet that doesn't work either.
class MyClass {
constructor() {
this.x = 0;
this.y = 0;
}
update(value) {
// logic
this.y = value;
return this;
}
}
var x = new MyClass();
x = x.update(1);
Using console.log(x) afterwards would once again result in y being 0, and not 1.
I'm aware of set and get, but then I wouldn't be able to perform any logic within update() or return anything.
Is this intended, or am I completely doing it wrong?
I would like to note that I'm using NodeJS.
I am doing something such as:
class.js ->
module.exports = /*class MyClass{}*/ (the above MyClass code)
app.js ->
let MyClass = require('class');
let x = new MyClass();
x.update(1);
console.log(x) (this returns the same value as x before calling update())
Calling x.y will result in 0
No it does. This suggests that your // logic is flawed. If there is no extra logic, the x.y property does end up as 1.
It works!
var x =new MyClass();
console.log(x.update(1)); //1
console.log(x.y); //1
Given is a simple, mathematically curried function to subtract numbers:
function sub(x) {
return function (y) {
return x - y;
};
};
sub(3)(2); // 1
The function signature reads exactly as the obtained result. The situation changes as soon as function composition is involved:
function comp(f) {
return function (g) {
return function (x) {
return f(g(x));
};
};
};
function gte(x) {
return function (y) {
return x >= y;
};
};
comp(gte(2))(sub(3)) (4); // true
With function composition, the last parameter of each function involved is crucial, as it is fed respectively with the value returned by the previously applied function. The composition in the above example reads therefore as: 4 - 3 >= 2 which would yield false. In fact, the computation behind the composition is: 2 >= 3 - 4, which yields true.
I can rewrite sub and gte easily to get the desired result:
function sub(y) {
return function (x) {
return x - y;
};
};
function gte(y) {
return function (x) {
return x >= y;
};
};
comp(gte(2))(sub(3)) (4); // false
But now the return values of directly called functions are different than expected:
sub(3)(2); // -1 (but reads like 1)
gte(2)(3); // true (but reads like false)
I could switch the arguments for each call or define a partial applied function for each case:
function flip(f) {
return function (x) {
return function (y) {
return f(y)(x);
};
};
}
flip(gte)(2)(3); // false
var gteFlipped = flip(gte);
gteFlipped(2)(3); // false
Both variants are obviously cumbersome and neither more readable.
Which parameter order is preferable? Or is there a mechanism to use both, depending on the respective requirements (like Haskell's left/right sections for partially applied operators)?
A possible solution must take into account, that I use unary functions only!
So you want to partially apply operators without having to write code like:
var gte2 = function (x) { return x >= 2; };
That's a reasonable use case, “to partially apply operators”.
The answer is simple. Just write a curried function. For example:
// var gte = y => x => x >= y; // ES6 syntax
var gte = function (y) {
return function (x) {
return x >= y;
};
};
var gte2 = gte(2);
Unfortunately, there are two ways we can partially apply binary operators:
Partially apply the operator to the left argument.
Partially apply the operator to the right argument.
This raises two important questions:
Which argument should the operator be partially applied to by default?
How do we partially apply the operator to the other argument?
Fortunately, we can agree on one thing: it makes no sense to provide both arguments to the operator.
// Why write the following:
add(2)(3)
// When you can write the following:
2 + 3
The reason we are creating curried operator functions in the first place is for partial application.
Hence, it makes no sense to provide both arguments to the function “at once”.
What are the ramifications of this restriction? It means that:
We can choose any argument order we want.
// This is correct:
var sub = x => y => x - y;
// So is this:
var sub = y => x => x - y;
It only needs to make sense given one argument.
// Consider this operator function:
var sub = y => x => x - y;
// This makes sense:
sub(1) // means (x => x - 1)
// However, this doesn't make sense:
sub(2)(3) // expected (2 - 3) but actually (3 - 2)
// But that's OK because it only needs to make sense given one argument.
Now, keeping this in mind which is the best argument order? Well, it depends.
For commutative operations the argument order doesn't matter.
For example, both addition and multiplication are commutative. Hence, a + b = b + a for addition and a * b = b * a for multiplication.
For non-commutative operations the right-to-left argument order is generally better because it allows the partial application to be read out loud.
For example, the expression lt(2) generally means x => x < 2 and not x => 2 < x.
Why is this the general case? Well, in JavaScript function names come before the argument. Hence, name(arg) naturally reads as x => x name arg instead of x => arg name x.
However, there are some exceptions to the second rule. Most prominently, division:
div(10) // is read out loud as divide 10 by x
// it is not read out loud as divide x by 10
Of course, the correct argument order for such edge cases is a matter of debate but in my humble opinion the left-to-right argument order seems more natural.
So, here are a bunch of curried operator functions:
// Commutative operators:
var add = x => y => x + y;
var mul = x => y => x * y;
// Right-to-left operators:
var lt = y => x => x < y;
var gt = y => x => x > y;
var lte = y => x => x <= y;
var gte = y => x => x >= y;
var sub = y => x => x - y;
// Left-to-right operators:
var div = x => y => x / y;
Now, the second question is how do we partially apply the operators to “other” argument?
The only way to do so it to create a new function with the flipped argument order.
Fortunately, we don't need to create a new function for every operator:
For commutative operators the argument order doesn't matter. Hence:
flip(add) = add
flip(mul) = mul
For relational operators we don't need to create extra functions:
flip(lt) = gt
flip(gt) = lt
flip(lte) = gte
flip(gte) = lte
We only need to create flipped operator functions for sub and div:
var subFrom = x => y => x - y; // subFrom(5) means (y => 5 - y)
var divBy = y => x => x / y; // divBy(10) means (x => x / 10)
All things considered, I would say that you should use your common sense.
Here's how I read your composition:
comp(gte(2))(sub(3)) (4);
gte(2) = function(y) { return 2 >= y; } // (x = 2)
sub(3) = function(y) { return 3 - y; } // (x = 3)
// Therefore:
comp(gte(2))(sub(3)) = function(x) {
var f = function(y) { return 2 >= y; };
var g = function(y) { return 3 - y; };
return f(g(x));
};
// Now call with (x = 4):
x = 4
g(4) = 3 - 4 = -1
f(-1) = (2 >= -1) = true
So in short, it seems that your expectations are wrong. Maybe you do indeed have something backwards, but I honestly can't tell what. I do, however, think that this is not a good way to work in JavaScript and you're overcomplicating things, but that's just my opinion.
This response is based on the reply from Aadit.
There is actually a need for fully applied curried operator functions in Javascript - when used as First Class Citizens:
function between(ops) {
return function (left) {
return function (right) {
return function (n) {
// At this point one should use the native Javascript operators
// but they can't be passed to the function, since operators are not First Class.
return ops[0](left)(n) && ops[1](right)(n);
};
};
};
}
function lte(y) { return function (x) { return x <= y; }; }
function gt(y) { return function (x) { return x > y; }; }
between([gt, lte])(2)(4)(4); // true
// is evaluated as: gt(2)(4) && lte(4)(4) === true; (confusing)
between may be nonsense, but it serves as proof that fully applied curried operator functions make sense in Javascript. There are likely even other use cases.
Nevertheless Aadit is right that something like sub(2)(3) contradicts the very purpose of currying!
So how could a solution look like?
all curried operator functions must have a right-to-left argument order
a function is introduced, which explicitly indicates the unusual usage when passing all arguments to a curried function at once
Here is uncurryOp:
// intended for all operator functions
function uncurryOp(f) {
return function (x, y) {
return f(y)(x);
};
}
uncurryOp(gt)(2, 4); // false (intuitive)
This is not really an adequate solution. I think there is no, due to lack of First Class and partially applicable operators in Javascript.
Apparently this is identical in my Firebug console:
var x = "A", y = x;
x + y === "AA";
and
var x = y, y = "A";
x + y === "AA";
Is this standard ECMAScript behaviour, that the order doesn't play a role in comma-separated var assignments?
Edit: The "mystery" is solved. I tested the first example first, then cleared the console and ran the second. However, at this time, y and x were already defined. If you run the JSFiddle provided by David Thomas you always get an "undefinedA". Case settled.
var x = y; will raise an exception if y is not defined.
However, the window object is the default context for Javascript interpreters embedded in browsers. If you previously issued:
y = "A";
Then you actually assigned "A" to window.y, therefore var x = y; becomes valid and assigns window.y to x.
i have a javascript code fragment as
var u = {};
var x = y = z = {"cvalue":"cell", "call":function(){alert(this.cvalue);}};
(function(){u=x;/*change all cvalue in x,y, z, u*/ u.cvalue = "notcell";})();
if(u == x && x == y && y == z && z == u){
u.call();
}
//only u goes to null
u = null;
//x,y,z stay same
alert(x.cvalue);
wondering why u = null only applies for u?
Variables don't actually hold an object, but simply hold a reference to one. By assigning u to null, you're dropping the reference that u had to the object.
A more basic example:
var x = { 'name': 'Bob' };
var y = x;
console.log(x); // Object { name="Bob"}
console.log(y); // Object { name="Bob"}
y.name = 'Jack';
console.log(x); // Object { name="Jack"}
console.log(y); // Object { name="Jack"}
x = null;
console.log(x); // null
console.log(y); // Object { name="Jack"}
Note how our object isn't held in x. It's held somewhere in memory, and x is referring to it. When we do y = x, we copy the reference to y, and therefore y begins to refer to the same object. Setting x to null simply drops the reference that x holds to the object, leaving the actual object unaffected. If we were to set y to null, or to anything else, the garbage collector would eventually pick up the object for destruction.
Daniel is right, but you have to be careful because in Javascript you are sometimes dealing with a copy, and othertimes dealing with the original. For example...
var a = new Object();
a.foo = new function(){alert("I exist")};
var b = a;
b.foo = null;//this erases the function from both a and b (technically, there is only one since a and b point to the same place in memory).
a.foo();//this now fails since there is no longer a function called foo
b = null;//this does NOT affect a in any way as per Daneiel Vassallo's explanation.
You are assigning the exact same object to x, y and z, not a copy of it's value, but the exact same object.
In pseudo code:
var u = OBJECT_A // u points to OBJECT_A
var x = y = z = OBJECT_B // x y and z points to OBJECT_B
(function(){
u=x; // Drop reference to OBJECT_A and point to OBJECT_B
/*change all cvalue in x,y, z, u*/
u.cvalue = "notcell"; //Changes the cvalue in OBJECT_B
// Remember x,y,z, and u points to OBJECT B
// so x.cvalue, y.cvalue, z.cvalue and u.cvalue is the same
})();
if(u == x && x == y && y == z && z == u){
u.call();
}
//only u goes to null
u = null; // Drop reference to OBJECT_B and point to NULL.
//x,y,z still points to OBJECT_B
alert(x.cvalue);