Java scriptconfusingbits

JAVASCRIPT: THE CONFUSING BITSJSON Dean

cf.Objective() 2014

Who am I?

This guy

Otherwise nobody

ARE YOU CONFUSED?I was

JavaScript is the most confusing thing I have ever tried to learn

JavaScript is not your parents’ programming language

No Classes

Unusual inheritance

Changing scopes

Weird object creation

Functions with functions

Unusual variable behavior

What this session isn’t

This session is not an intro to JavaScript

You have worked with JavaScript for a while

This session is not about politics, muscle cars, your DVR, or anything else you may find confusing

Scoping

ScopingJavaScript Scopes !== C-Style Scopes

JavaScript does not have block scope

CFML developers are used to this

If you create a variable it does NOT live in the context of the “block” where it was created (if, loop, etc).

The variable lives in the execution context where is was created

Execution context was a new term for me

Function ScopeJavaScript has “function scope” or “execution context”

When a variable is created, it is created in that scope

The execution context where it was created

The function in which it was created

var x = 1; function doSomething() { for (i = 1; i < 10; i++) { x += i; } } doSomething(); console.log(x);






Variable created in the global scope






Variable from the global scope is used






Variable from the global scope was updated by

doSomething()

var x = 1; function doSomething() { var x = 1; for (i = 1; i < 10; i++) { x += i; } console.log( "Function Scope Variable: " + x); } doSomething(); console.log( "Global Scope Scope Variable: " + x);












Variable created in the global scope







Another variable created in the scope of the doSomething()

function scope







The function scope variable was changed







The global scope variable was unchanged

Variable Hoisting

“JavaScript is the world’s most misunderstood programming

language” !

- Douglas Crockford

Variable Hoisting

var foo = 1; function bar() { if (foo == undefined) { var foo = 10; } console.log(foo); } bar();

Consider this simple example

Variable Hoisting



Any reasonable person would look at

this and say…

Variable Hoisting



OK… I’m creating a variable called foo

Variable Hoisting



And a function called bar()

Variable Hoisting



Then I’m calling bar()

Variable Hoisting



bar() checks to see if foo is defined

Variable Hoisting



If foo isn’t defined, then it gets defined with a value of 10

Variable Hoisting



Then foo gets logged out

Variable Hoisting


Consider this simple exampleWell, we know foo is defined, with a

value of 1.

Variable Hoisting



So this should log a 1, right?

Variable Hoisting



Variable Hoisting



Wait… what?

Variable Hoisting



So what happened?

What we just saw is confusing

Why is the value 10 and not 1?

The answer is a combination of

Function Scope

And variable hoisting

So what is variable hoisting?Function and Variable declarations get “hoisted” to the top of the executable context

Functions first

Then variables

So the JavaScript engine is rewriting our code

Let’s see how

Variable Hoisting


JavaScript rewriting our code

Variable Hoisting


JavaScript rewriting our codebar() is a function, so it gets hoisted first to

the top of the execution context

Variable Hoisting



In the case, it is the global context

Variable Hoisting



function bar() { if (foo == undefined) { var foo = 10; } console.log(foo); } !var foo = 1; bar();

Variable Hoisting




Next our variables get hoisted.

Variable Hoisting




Next our variables get hoisted.

Wait… did he says “variableS”? There’s one variable, it’s foo,

right?

Variable Hoisting




function bar() { var foo; if (foo == undefined) { foo = 10; } console.log(foo); } !var foo; foo = 1; bar();

Variable Hoisting





So our foo variable from the global scope got hoisted,

though not very far.

Variable Hoisting





It is now at the top of the global execution context,

below any function from the same context.

Variable Hoisting





But what’s this? Our foo variable in the function also got

hoisted to the top of its execution context.

Variable Hoisting





So we (or at least, I) thought that the if statement was

checking to see if the global variable existed.

Variable Hoisting





But after JavaScript’s rewrite we see it is actually checking to see if this variable is undefined.

!Is it?

Variable Hoisting





A variable that has not been assigned a value is

of type undefined. !

-MDN

Variable Hoisting





So foo is undefined! It exists, but has not been given a value

Variable Hoisting





So foo receives a value of 10 because it is previously

undefined

Variable Hoisting





This foo remains unchanged in the global scope. If we were to

log again here, we’d see a 1

Variable Hoisting





var foo = 1; function bar() { if (foo == undefined) { var foo = 10; } console.log( "Function Scope Variable: " + foo); } bar(); console.log( "Global Scope Variable: " + foo);

So why did this happen?


It gets more confusing




We’ll make a small change to this code




We’ll make a small change to this code

var foo = 1; function bar() { if (foo == undefined) { foo = 10; } console.log( "Function Scope Variable: " + foo); } bar(); console.log( "Global Scope Variable: " + foo);





Did you see it?





Right there. I took out the var





So now what happens?





Exactly what we expected to happen

the first time!





Huh?

var?So all we did was remove var from the variable assignment

Why does that matter?

Again, this will be familiar to CFML developers

The use of var will cause the creation of the variable in the local scope (the execution context)

Failure to use var will result in the JS engine searching through the scope chain for the variable

If it doesn’t find the variable by the time it reaches the global scope, it will create it there

var


Let’s look at this again

var


Let’s look at this againHere we might think that the variable will only be created if the if statement evaluates to

true

var



var foo = 1; function bar() { var foo; if (foo == undefined) { foo = 10; } console.log( "Function Scope Variable: " + foo); } bar(); console.log( "Global Scope Variable: " + foo);

But after that variable is hoisted we can see that it will

exist (though it will be undefined) regardless of the if

statement

var




It doesn’t matter that the variable already exists here, because this is in a different

scope

var




No var

var foo = 1; function bar() { foo = 10; } bar(); console.log( "Global Scope Variable: " + foo);

One more time

No var


One more timeWhen var is not used in the assignment, the JavaScript engine will search for the

variable instead of creating it

No var


One more time

First it will look in the function context

No var


One more time

Then it will look in the next scope in the chain, in this case,

it is the global scope and it will find it.

No var


One more time

function bar() { foo = 10; } bar(); console.log( "Global Scope Variable: " + foo);

It it doesn’t find it in the global scope, it will create it there.

PROTOTYPAL INHERITANCEObjects from Objects

JavaScript PrototypesObjects inherit from objects. What could be more object oriented than that? - Douglas Crockford

In JavaScript objects can be created from other objects

This can be accomplished in several ways

Many consider it very elegant

Classical Inheritance

Classical InheritanceSuper-Class


Sub-Class

Prototypal InheritanceCreating objects that inherit from other objects

Can only be done with two object creation methods

Constructor Functions

Object.create()

Either one is acceptable, but Object.create is recommended by many experts

Object.create() is not supported by all browsers, but that is easily fixed with Webshim Lib or other polyfills

Prototypal Inheritance

Prototypal InheritancePrototypes are how one object inherit

from another object


The inheritance “feels” like classical

OO inheritance when you use it

Prototypal InheritanceBut internally, it is

very different

Prototypal InheritanceEvery object has a

prototype, an object that it inherits from


The prototype of an object is actually a property of that

object


Unless you explicitly create one without.


Even then, it still has one, it is null

Prototypal InheritanceEvery object has a __proto__ property

Every object has a __proto__ property




Prototypal InheritanceEvery object has a __proto__ property





In modern browsers

__proto__

__proto__ should NEVER be used in production (it is deprecated)

__proto__ is a great learning tool though

We can use __proto__ to look at an object’s prototype in the console

You can also access an object’s prototype using Object.getPrototypeOf(object) (using Webshim Lib to support older browsers)

Prototypal Inheritancevar Car = { wheelCount: 4, motor: null, go: function() { console.log( "Vrooooom!!!" ) }}; var chevette = Object.create( Car ); chevette.motor = { cylinder: 4 }; chevette.go(); console.log( Car.isPrototypeOf( chevette ) ); console.log( chevette );


Simplified example


Create an object from which we will inherit

properties and methods


Create a new object that inherits from Car (more on this in a bit)


Assign a new property to the new object


Call an inherited method, just to see if it

works


Examine the new object

Prototypal InheritanceThe result

Prototypal InheritanceThe result

var Car = { wheelCount: 4, motor: null, go: function() { console.log( "Vrooooom!!!" ) }}; var chevette = Object.create( Car ); chevette.motor = { cylinder: 4 }; chevette.go(); console.log( Car.isPrototypeOf( chevette ) ); console.log( chevette );



Our inherited method ran



Car is, indeed, the prototype of chevette



The new object



The new motor property of the

object



But wait… why doesn’t our object have a wheelCount

property or a go() method?



There they are, in the objects __proto__

property



But wait… the motor there is null. Can we access the wheelCount? How does

JavaScript know which motor to use?

Prototypal InheritanceWhen you request a property from an object:

JavaScript checks for that property in the object

If it does not exist, it checks the object’s prototype (__proto__)

If it does not exist, it checks the object’s prototype’s prototype

It continues until it reaches the top level object

This is referred to as the Prototype chain

If a property exists in more than one object in the prototype chain, the first one JS comes across is the one it will use



So if anything requests the motor property from

our chevette



It will find this one first in the chain



Not this one



If chevette didn’t have a motor property, it

would find the one in the prototype

Functions as First Class Objects

In JavaScript, Functions are first-class objects

They can have properties and methods of their own

They can be passed as arguments

They can be returned from functions

They can be properties of other objects

Function PrototypesThis is where things get confusing

As we know, all objects have a prototype

That prototype is store internally in __proto__

Function Objects also have a prototype property, which we’ll refer to as the ‘Function Prototype’

The function prototype is NOT the function’s prototype (confused yet?)

The function object still has a __proto__ that contains its prototype







The function prototype is the object that will become the __proto__ property of

any new object created from that function if that function is used as a

constructor function


Are just regular functions

When combined with the new keyword they behave differently

When used with new the function becomes a factory and creates a brand new object

this becomes bound to the new object being created

this is then automatically return by the constructor

Constructor Functionsfunction Car() {} Car.prototype.wheelCount = 4; Car.prototype.motor = null; Car.prototype.go = function() { console.log( 'Vroooom!!!!' ); } var chevette = new Car(); chevette.motor = { cylinder: 4 }; chevette.go(); console.log( chevette instanceof Car ); console.log( chevette ); !


Just a regular function


We then modify the function’s prototype to

add inheritable properties and methods


When we use the new keyword to create the

object…


Our regular function becomes a factory

function. !

Returns this automatically


Here is where the difference lies


The new object does not have Car() as its

prototype


It has Car()’s prototype as its prototype


So chevette.__proto__ == Car.prototype

__proto__ and prototypeEvery object has a __proto__

__proto__ is a property

__proto__ references the object that is being inherited from

Only Function objects have a prototype property (in addition to __proto__)

A Function’s prototype references the object that will become the __proto__ property of new objects created from this function

if used as a constructor

Constructor FunctionsBehaves like our

Object.create() object


It has a __proto__ like our Object.create() object

Constructor FunctionsBut now we have this constructor property


And in there is where we find the prototype object from which we

are inheriting


So why all this prototype stuff?


You said that the constructor automatically returns this, why

not just use that?


Let’s try it

this

function Car() { this.wheelCount = 4; this.motor = null; this.go = function () { console.log( 'Vrooommmm!!!' ); } } var chevette = new Car(); chevette.motor = { cylinder: 4 }; chevette.go(); console.log( chevette instanceof Car ); console.log( chevette );

this


Just a regular function

this


We then modify the function’s this object to

add properties and methods

this


Remember, when we use new, this is bound

to the new object

this


So hey! Look! Our new object will have the

properties and methods, right?

this


The answer is YES. But they won’t be inherited

this


Prototypal InheritanceWorks similarly to our other examples


But, if we inspect the object we see…


The object has its own copy of the properties

and methods


It still has Car as its __proto__


And it would still inherit the properties and methods of Car’s

prototype


But, in this case, Car has no new properties and

methods


What we’ve created are instance variables

Why not use this for everything?

When you use this new objects do not inherit those properties and methods

They get their own copies

If you change the this scope properties or methods in the prototype object the existing objects will not inherit the changes

The best option is to combine prototypal inheritance with instance variables to get what we want

Prototypal InheritanceSo let’s think about how Car should work

We’ll create a new object that uses inherited and instance properties and methods to meet our needs

Car spec:

Each instance of Car should have its own name, wheelCount, color, and motor

All instances of Car should have the same methods for go(), addFuel(), brake(), and about()


Our Car constructor


Of course, our constructor is only a

constructor if we remember to use new.


Add our methods to the Car constructor’s

prototype


This method will be inherited from the

prototype


But when it access the this scope it will be getting instance variables


We’ll create some new Cars


And then do some stuff with them

Prototypal InheritanceAll of our inherited methods worked

correctly


And our instance variables are unique to

each instance

Back to Object.create()


We look at prototypal inheritance with Object.create()



But we didn’t look at instance variables



But we didn’t look at instance variables

Let’s see how our Car example might look with instance variables


Simple object with methods to be inherited


Use Object.create to create new objects that

inherit from Car


One way of getting instance variables


Is with this crap


These are called property descriptors


If you don’t explicitly specify writable, enumerable, or

configurable, they won’t be.


So in this example, only color can be changed after the object is constructed


Other than the properties being non-writable, non-configurable, and non-enumerable (except for color) this

works the same as the other examples


But it sucks


I think this is a bit easier to look at


We create an init() method for all

objects to inherit


This works just like our constructor

before


But we must explicitly return this


Soooooo much better than those

property descriptors


Still working

But wait… there’s more


We can use the same functions we were using before for constructors with Object.create()



The new object will still inherit from the function prototype



The new object will still inherit from the function prototype

But the constructor function never actually fires, so we can’t use it from constructing the object with instance variables


We can use a function


And modify its prototype


Then use Object.create()


Note we are passing in Car’s prototype, not Car


Car’s prototype is where the methods we

want to inherit are


Unfortunately, the constructor never runs, these variables are not

added as instance variables


Still inheriting the prototype’s methods


But no properties


We could use property descriptors again… but

who’d want to?


We can use an init() method again


Then call it like we did before after passing the function prototype into

Object.create()

So???So which one should I use?!?!?!

I bet you were hoping for an answer

A lot of experts will tell you to use Object.create(). But which way should you use Object.create()?

Some will tell you that new is evil, others will tell you the truth. new is not evil

Pick one way and stick with it

My preference is for Object.create(SimpleObject).init() or new ConstructorFunction()


Object.create(SimpleObject).init()


new ConstructorFunction()

Closure Examplefunction makeAdder(howMuch) { return function (addTo) { return addTo + howMuch; } } //Make a 5 addervar add5 = makeAdder(5); //Make a 10 addervar add10 = makeAdder(10); console.log( add5(10) ); // 15console.log( add10(20) ); //30


The makeAdder() function will create and a return a

new function


Normally we would expect that when this function

finishes running…


… that its scope would no longer exist, including the

howMuch argument


When we call makeAdder()


howMuch is equal to 5


The function then returns another function (but does not

execute it)


So how then, does howMuch still exist when …


We call the new function


Because the returned function is a closure


Not only does it have access to its own scope,

where addTo exists


It has access to the scope that it was in when it was

created


Where howMuch exists and is equal to 5

Closures

In basic terms, a Closure is a function that maintains the context in which is was created in addition to its own

I am not going to delve deeply into closures, Adam will do that later

The changing this scopeA function that is the property of another object is called a “Method” of that object

When a method is called as a property of an Object, this refers back to the object

The object assigned to this changes depending on where and how the function is called

NOT by where or how it is defined

If you don’t call a function correctly, it could break

This is a source of confusion for many developers (me included)

Changing this scopevar name = "Global"; var testObj = { name : "Test Object 1", about : function() { return this.name; } } var testObj2 = { name : "Test Object 2"} console.log( testObj.about() ); var outerAbout = testObj.about; console.log( outerAbout() ); testObj2.about = outerAbout; console.log( testObj2.about() );


Create a function that will return the value of this.name


Ensure name exists in all available scopes




Call about() on testObj


Add about() reference to a

global variable, call it again


Add about() reference to testObj2, call it again


All three about()s reference the same function

Confusing

So what if we want to control the context?

We can define to which object this is bound

We can do this using call() and apply()

Call vs. Apply

Each takes the function context as the first argument

That is the object that will become this

call() takes each additional argument as parameters to the function

apply() takes only one extra argument which is array of values that will be used as parameters to the function

Defining this var name = "Global"; testObj = { name : "Test Object 1", about : function(additionalString) { return this.name + ' ' + additionalString; } } testObj2 = { name : "Test Object 2" } console.log( testObj.about("is awesome") ); var outerAbout = testObj.about; console.log( outerAbout.call(testObj, "Is Awesome") ); testObj2.about = outerAbout; console.log( testObj2.about.apply(testObj, ["is awesome"]) );


Modified about() to take an argument


Call about() normally, will be bound to testObj


Call about() about from the global scope

using call()


Passing in testObj will cause this to be bound

to testObj


We pass in additional arguments, they will be passed on to about()


Call about() from testObj2 using apply()


Passing in testObj will cause this to be bound

to testObj


We pass in additional arguments as an array of arguments, they will be passed on to about()

Thank You

Questions?

!

Jason Dean

@jasonpdean

http://www.12robots.com

http://www.12robots.com

Java scriptconfusingbits

Technology

Transcript of Java scriptconfusingbits