javascript - Timeout with bind, call & apply methods -


up until now, i've used var self = this before creating function need access parent. bind() method seems more appropriate way , i'm exploring option, along apply() , call() methods.

this came compare three:

jsfiddle

(function(){        this.say = function(text){                    console.log(text);      }                this.run = function(){                    console.clear();                    settimeout(function(){              this.say('bind');          }.bind(this), 1000);                    settimeout(function(){              this.say('call');          }.call(this), 1000);                    settimeout(function(){              this.say('apply');          }.apply(this), 1000);      }            this.run();        })();

but script leaves me questions:

  1. why don't call() , apply() methods respect timeout bind() method , 1 should use?

  2. is there difference between following syntaxes behave similarly:

    settimeout( function(){ this.say('bind'); }.bind(this) , 1000);  settimeout( (function(){ this.say('bind'); }).bind(this) , 1000);  settimeout( (function(){ this.say('bind'); }.bind(this)) , 1000); 

you're missing key point here (but key point obfuscated in documentation).

you know whenever write function this:

function something() {     // ... whatever } 

it's function reference sitting there itself. hasn't been called yet.

when write this:

(function something() {  })() 

or this:

function something() { ... }  something(); 

you've called function. 2 different concepts.

in first 1 function sitting there without having been called, it's referred function reference, , that's .bind returns: a function reference.

.call , .apply return return value of whatever function, in new context. in fake javascript la-la land, this:

function() {  }.bind(this)  // returns function reference: function() {  } 

whereas:

function() {     return 'hello'; }.call(this) // returns hello... not function reference! 

you see...

you never this:

function hello() {     return true; }  settimeout(hello(), 100); 

you'd error: settimeout expected function, , received boolean, or that.

function error

^ that's not semantic error, it's error nonetheless.

but, would this:

function hello() {     return true; }  settimeout(hello, 100); 

see difference? last example okay, because passed in function reference.

because internally, settimeout this:

window.settimeout = function(callback) {     // bunch of other stuff, and...      callback(); }; 

as far second question goes...

those pretty equivalent. closures make sense though whenever you're declaring variables don't want give other objects access to.

to understand closures little bit, let's pretend we're not talking javascript.

in math, know how can a + b * c?

well, when group them parentheses, kind of changes behavior: (a + b) * c.

now, that's not quite related javascript in sense in javascript we're not worried order of operations (unless you're doing math in javascript), whole idea parentheses act container (what call closure) whatever inside of it.

so when put function inside parentheses, you're hiding function outside world, can still return stuff, , can still have access parent scopes (like window, example).

a cool example:

var name = (function(name) {     return name })(function() {     return 'jane'; }());  console.log(name); // => jane 

Comments

Popular posts from this blog

powershell Start-Process exit code -1073741502 when used with Credential from a windows service environment -

twig - Using Twigbridge in a Laravel 5.1 Package -

c# - LINQ join Entities from HashSet's, Join vs Dictionary vs HashSet performance -