Default parameters aren't assigned to the arguments Array like Object :
function fn(test = "test") {
console.log(arguments); //[]
}
This might be usefull to know only what the user passes to the function, but it seems tricky too.
Will this change?
No, this will not change.
In fact it already did change - previously every index on the arguments object was mapped to the respective parameter variable for reading and writing (a horror to reason about!). This proved to have devastating performance implications as it prevented a lot of engine optimisations, and was deprecated in ES5 (however, for compatibility reasons, only in the new strict mode). In ES6, the behavior is also deprecated in sloppy mode functions if they use new ES6 features in their parameter list (like destructuring, default initialisers or rest syntax).
The arguments object is just a simple object with the argument values that were passed to the function. Notice that defaults are not passed, it's just syntactic sugar for initialising variables in the begin of the function body.
If mapped to scope variables, it's much more complicated.
Related
I read that functions (AKA static methods) are objects (instances of the Function class). Are methods (instance functions) also objects? I can't find the answer in the official documentation. It only says functions are objects (but doesn't explain if all functions are, including methods).
It is quite easy to verify that the method is an object:
class Foo {
bar() {}
}
void main() {
print(Foo().bar is Object); // prints true
}
and linter shows a warning:
Unnecessary type check, the result is always true
Technically, the answer is "no". In practice, that never matters.
Instance methods are properties of classes that can be invoked via objects that are instances of those classes. A method is not itself a value, so it makes not sense to ask if it's an object, because all objects are values. You can refer to a method by name (it's "denotable"), but that's it. You cannot evaluate an expression to a method or store it in a variable.
However, you can tear off an instance method from an object. When you do that, a new function object is created which, when called, will invoke the method on the original object with the same arguments.
That function object is, well, both a function and an object. It is not the method itself, though, if one is being pedantic.
In practice, if you ever care to ask if something is an object, it's likely already a value, and then that thing is an object.
(Static methods are also technically not objects, but they are so close to the function object created when you tear them off, that the distinction is never practically significant. The language semantics differentiates because when you create an object, it matters which object it is - what is it equal to and identical to - and until you creates a value, the language prefers to just not have to specify that.)
I was creating a function and I tried to increase the value of the parameter which was declared as Integer. But it said that the value of that parameter can not be reassigned. I am a beginner so if I am missing some concept please tell me.
Yes, in Kotlin function parameters can't be changed.
(However, if they refer to mutable objects, then those objects can change. For example, if you declared fun a(b: List<String>), then you could add another String to the List; but you couldn't set b to refer to a different List.)
This is different from Java, where parameters are variable (unless specified as final).
This behaviour was announced in Kotlin milestone M5.1, where it was explained as avoiding confusion (especially in constructors), and promoting good style.
See also this answer.
In ES5, Boolean.prototype is a Boolean object:
The Boolean prototype object is itself a Boolean object (its [[Class]] is "Boolean") whose value is false.
In ES6 / ES2015, it isn't:
The Boolean prototype object is an ordinary object. It is not a Boolean instance and does not have a [[BooleanData]] internal slot.
In ES2016, it is once again:
The Boolean prototype is itself a Boolean object; it has a [[BooleanData]] internal slot with the value false.
(and it remains so in ES2017 as well.)
The same is true for Number.prototype and String.prototype—while on the other hand Date.prototype and RegExp.prototype also began as instances of their respective [[Class]]es in ES5.1, became plain Objects in ES6 and have remained that way since.
The reversion, in ES2016, does not appear to have been the subject of any tc39 proposal.
Why were these changes made in ES6, and then (only) partially reverted in ES2016?
(This question is not just for academic/historical interest: I am working on a JavaScript dialect that is intended not to include the boxed primitive types but which still requires the .prototype objects to hold all the methods that can be invoked on primitive values, and while it's feasible to special-case the .prototype objects as being the only instances of their respective [[Class]]es, I'd like to understand why that might be desirable.)
I have not been able to find an full explanation of why these objects became plain Objects in ES6, but the reason for the rollback appears to be because it caused unexpected problems: from "Number.prototype not being an instance breaks the web, too" on esdiscuss.org:
V8 just rolled a change into Canary yesterday that implements the new ES6 semantics for Number.prototype (and Boolean.prototype) being ordinary objects. Unfortunately, that seems to break the web. In particular jsfiddle.net/#run fails to load now.
What I see happening on that page is a TypeError "Number.prototype.valueOf is not generic" being thrown in this function (probably part of moo tools):
Number.prototype.$family = function(){
return isFinite(this) ? 'number' : 'null';
}.hide();
after being invoked on Number.prototype.
AFAICS, that leaves only one option: backing out of this spec change.
–Andreas Rossberg
And it seems that the rollback was not applied to Date.prototype and RegExp.prototype because they carry mutable state:
From a security pov, the important ones not to revert are those carrying mutable state not locked down by Object.freeze. In ES5 this was only Date.prototype. Of the ES5 builtins in ES6, this now includes RegExp.prototype because of RegExp.prototype.compile.
—Mark S. Miller
Are there any rules (or will I run into any problems) if I name the parameters of a function the same as the variable I will pass into them?
For example in Python:
def foo(param):
pass
param = 2
foo(param)
In the fairly limited programming I've done, I have not ran into any problems doing this. Will I get problems in certain languages? Is this okay to do, or is it a practice to be avoided?
The "problem" in this particular case is that the function parameter name will shadow the outer param variable; i.e. you cannot (implicitly) refer to the global param anymore because inside your function param is defined as a local variable.
But, this is really as it should be. Your function should only worry about the parameters it declares locally, not about implicit global variables. Conversely, a caller of a function should not have to worry about anything that goes on inside a function. Naming a variable the same as a parameter to a function is of no consequence to the caller, and should be of no consequence to the function itself.
So, no, there's absolutely no issue here.
I was testing Jakobs patch on the Sortables Class and this line this.reset() gave me a Uncaught TypeError: undefined is not a function.
I don't understand why since the Class has a method reset.
So my solution was to a var self = this; inside the same end: method (here), and called self.reset(); in the same line as I had this.reset(); before. Worked good. Why?
Then just to check (I suspected already) I did a console.log(this == self) and gave false.
Why does using self work but not this?
Fiddle
In javascript the this keyword change accordingly with the execution context
in global code this refer to the global object
inside eval the scope is the same as the calling context one, if no context provided then is the same as above
in all the case below if the this argument passed to .bind .call or .apply is not an object (or null) this will be the global object
when using a function which has been binded to a specific object using .bind then this refers to the this argument passed to bind, the function is now permabinded.
when running a function the context is provided from the caller, if before the function call operator () there is a dot(.) or a [] operator then this refers to the part on the left of such operator, unless the function is permabinded to something else or we are using .call or .apply if so this refers to the this argument unless the function was previously permabinded;
if before the function call operator () there neither the . nor the [] operators then this will refer to the global object (unless the function stores the result of the .bind function)
when running a constructor function (basically when using new) this refers to the object we are creating
now when using the use strict directive things changes a bit, mostly instead of the global object when the context is not given this will be null, but not in all the cases.
I rarely use "use strict" so I just suggest to try it by yourself when in need.
now, what happens when a function is cached inside a variable like this:
var cache = 'A.foo'
if that you lose the context in which the original function was stored, so in this case foo will not be anymore a property on the instance A and when you run it using
cache()
the context will be evaluated using the rules I wrote above in this case the this will refer to the global object.
The semantics of "this" in Javascript are not what is expected by OO programmers. The symbol "this" refers to the dynamic/runtime calling context, not the lexicographic context. For example, if you have an object A with "method" and then do B.method = A.method; B.method(); then the context is now B and that is what this will point to. The difference becomes very apparent in "handler" type situations where the calling context is usually the object with the handler installed.
Your solution using self is sound.
kentaromiura's answer is absolutely right.
That said, mootools provides function.bind() as a way to decide what this will refer inside of your function. this means that if you simply do this :
var destroy = function () {
`bind() [...]
this.reset();
}.bind(this);
it will work as you intended (that is, this will be the same inside of destroy() and outside).
Now, a lot of coders will balk at fiddling with the context, with good reason as it is very difficult to read and maintain. But here you have it and I think bind() is a very nifty trick of mootools.