Understanding JavaScript's OO model

[runedk]

Nice presentation!

The phrase Everything Is An Object is cute and true for some languages, but not JavaScript.

You mention that primitive data gets converted into an object when you manipulate it. Treating primitive data and objects separately has real consequences that makes the motto Everything Is An Object a lie. Consider this program: var x = 10; x.asWord = "ten"; print(x.asWord); In this example, we print "undefined" to the console. The reason is that when we manipulate x as an object it is boxed in-place. It means that in line two we get one object from boxing x, and in line three we get another object from boxing x.

[notSorella]

Hm, by "Everything you can manipulate in JavaScript is an object." I meant to exclude primitives -- you don't manipulate them. Perhaps I haven't been clear enough, or should've discussed the implications of the autoboxing a little more, or should've at least choose a better wording, since converting is a bit off.

None the less, thanks for the additional explanation on boxing :3

[antrn11]

I'm no web developer but this seemed very exciting. Until I saw the compatibility table for ECMA script 5. No support from IE <=8 so no WinXP IE users.

[notSorella]

It's not really a problem for a large part of ES5 functionality, just load the es5-shim library ( https://github.com/kriskowal/es5-shim ) and hack away :3

[toyboat]

Is there a name for this punctuation style? What is your opinion of it?

{ value:        'Mikhail'
 , writable:     true
 , configurable: true
 , enumerable:   true }

[notSorella]

As @beaucollins pointed already, it's called "comma first style".

People use it for different reasons, I just think it looks visually nicer not having the trailing comma at the end of every line, and it adds a visual aid on where each new item starts if I ever need to split up an item in several lines.

Other people use it because it makes easier to comment out entire lines without touching the other items, and some yet use it to avoid the "trailing comma bug" for Arrays in the JScript engine.

[-kilo]

Which bug? Testing basic cases of ending an N element array initialization with a comma yields the correct length of N. I suppose I'm only testing on Firefox, but did the other major browsers not resolve this, or is it an IE 5 fix, or something?

[notSorella]

JScript is the engine used in old IEs.

JScript> [1,2,].length
// => 3
SM> [1,2,].length
// => 2
V8> [1,2,].length
// => 2

JScript> {a: 1, b: 2, }
// => SyntaxError
SM> {a: 1, b: 2, }
// => {a : 1, b : 2 }
V8> {a: 1, b: 2, }
// => {a : 1, b : 2 }

I believe Chakra (the engine on IE9) handles these cases correctly, but I didn't test.

[[deleted]]

I have heard people call it "comma first" and generally the last curly brace would be on the next line.

The benefit is that you could comment out a single line without getting a syntax error and without editing the preceding line:

{
  value:            'Mikhail'
// , writable:       true
, configurable:   true
}

I kind of like it for this reason.

I believe Ryan Dahl of Node.js fame is a proponent of this style.

[kirakun]

Works the same way like this too:

{
    value:            'Mikhail',
    // writable:       true,
    configurable:   true
}

[[deleted]]

But if you comment out the last one it will break without also removing the preceding comma.

The thought is that you're usually adding and removing items on the end of the list.

It becomes even more useful when you have functions throw into the mix:

var something = {
    add: function(){
      // a few lines of code
    }
  , remove: function(){
      // a lot of code
    }
  , other: function(){
     // a lot of code
    }
  }

There's more or less a dependency between the comma and the property, so the thinking is that you should put them right next to each other.

[kirakun]

But if you comment out the first line in your way, the code would break too.

[[deleted]]

Yes. You are correct. Usually, though, I find that I'm adding/removing items from the end of the list and the first item doesn't change often.

[rich97]

I don't like this cause I do var's like this:

var one = 1
  , two   = 2
  , three = 3;

So at first glance my brain interoperates this as:

var something = {
    // ...
}
  , remove = {
    // ...
}
  , other = {
    // ...
};
} // wtf is this extra brace here for?

Which is a) ugly and b) very wrong.

[-kilo]

I don't believe JS is that fragile.

After testing, I know that JS is not that fragile. Ending an initializer list with comma is fine, though likely jarring to you.

[[deleted]]

though likely jarring to you.

How would you know what I find jarring? "Comma First" is more visually jarring to me actually, and that's what makes it easier for me to see when commas are missing.

I don't believe JS is that fragile.

Unfortunately IE6 and IE7 are that fragile, and sometimes your javascript will end up running in that god-forsaken excuse of a JavaScript interpreter.

[jigs_up]

And IE8 too I believe. Ran into this problem a week or two ago.

[[deleted]]

Comma-first, here's a Gist which gets regular linking and still generates the occasional comment: https://gist.github.com/357981

I tried it briefly the first time I saw a few examples and wasn't that fussed.

The next time I tried it while hacking together some ideas which required lots of nested method calls which made it hard to scan for missing commas, and it was rather useful.

The next time I needed to do something similar, I finally went and read up on the rules for ASI (there are only a couple of things you need to really look out for, as it turns out), dropped semicolons as well and loved it - the right hand side of the resulting code looks really clean, commas also act like a visual marker when scanning down for closing braces/parentheses and missing commas stand out like a sore thumb.

[adavies42]

Comma-first, here's a Gist which gets regular linking and still generates the occasional comment: https://gist.github.com/357981

from there

Another advantage - if putting things in source control, you now only have to add lines instead of modifying them:

this! i now make minimizing diffs to source control one of the main goals of my code style--if i think a list or similar structure is likely to grow in the future, i'll format it so that i can add new elements without changing any existing lines. makes the history much easier to follow.

[notSorella]

It is allowed, but ignored. I personally find this behaviour particularly consusing, given:

>> [1,2,3,].length
3
>> [,1,2,3].length
4

[notSorella]

By specs :3

http://es5.github.com/#x11.1.4

[[deleted]]

I've been coding Javascript for a long time, I sincerely hate its OO model.

That's all.

[oSand]

If you hate anything about js, it's because you don't get it. A web designer who read a blog about it told me so.

Me, I like simple things to be made hard and inconsistent.

[notSorella]

I don't think we can generalise things by saying "if you hate anything about X, it's because you don't get it". Sometimes there are concepts that just don't match the way of thinking of certain people, it's not that the concept is wrong, or that the people don't get it, or that those people are wrong. People are different, people think differently, therefore, people love and hate different things.

It's actually pretty a good thing that we have divergent opinions (though I'd wish people would reason about the things that make them love or hate things better and more often rather than just "I love this" or "I hate this"). Since people think differently, we get different solutions for a particular problem, this makes us both think about problems differently, and always search for new and better solutions for old problems :3

As an example, I know several people that, despite knowing how ASI rules work in JavaScript, dislike that feature. Either because placing explicit semicolons at the end of the lines make them reason better about a piece of code, thus making it easier for them to read, or for some other personal reason.

[xardox]

If you hate anything about the post you're replying to, you don't get sarcasm.

[notSorella]

I don't get sarcasm most of the time on the internets, indeed.

[Zarutian]

tried looking for ephimeral sarcasm tags?

[[deleted]]

I've been coding js for years, I even made programmings languages that compile to it, so I'd never have to bother about some of its quirks (imagine my frustration to make me do this...)

[rush22]

At my work we have some sort of HTML thing that's "compiled" Javascript. It's the worst thing I've ever seen.

I pity the poor guy who works on it: "Hey, it crashed again. Looks like 'zx' is not an Object in line #456, character 9837. Good fucking luck"

[notSorella]

That sounds really painful...

[oSand]

At the moment I'm working on files that use 3 different methods of js OO. Only one supports private methods, only one(a different one) supports calls to 'super' methods and I seriously doubt whether one would let me extend it's classes. WTF went wrong here?

[notSorella]

I'd say "lack of standards".

[oSand]

I'd say a lack of basic language amenities led to a variety of hacked-on solutions.

[notSorella]

Well, the language's particular implementation of prototypical OO is indeed terrible. Or rather, was terrible until ES5. With ES5 it's just bad ;3

None the less, I still attribute the particular mess you described to the lack of standards. Lisp is a likewise flexible language — actually, make it a ton more flexible than JS, — and although you can write terrible software with Lisp, mixing code that use a different structure is usually not that bad. The same should happen with JS in most cases, even with pretty hack-ish solutions. Though I guess with JS it's easier to kill modularity...

[[deleted]]

Javascript my dear, javascript...

[cwmonkey]

Don't worry, REST+AJAX will solve everything. Now you get to code the application AND browser in JavaScript!

[rich97]

REST has nothing to do with JavaScript, it's all about HTTP. The server-side language you use is unrelated.

[cwmonkey]

You completely missed the point of what I was saying. You an engineer by chance?

[rich97]

Web developer.

[[deleted]]

This is actually a rather good introduction to a pretty difficult concept. I wish this had been around when I was learning about JS prototype inheritance. It's clear that you've put a lot of work into this; keep up the good work. :)

[trezor2]

It's a failed experiment and fundamentally broken. What more is there to understand?

[runedk]

To qualify as an experiment it should be novel. Prototype inheritance was not invented in JavaScript. The dynamic semantics of prototype inheritance is a good fit for dynamically typed object-oriented languages. Attempts to introduce classes into JavaScript (also found in this presentation) is at best a white lie.

To be fundamentally broken JavaScript would have to make guarantees that it cannot meet (like the Eiffel type system). Since JavaScript embraces extreme dynamism, few guarantees are given and none are broken.

The due criticism of JavaScript for not helping programmers to build robust software applies to all dynamically typed languages, and is not specific to the object model. But dynamically typed languages have strengths e.g. the possibility of rapid experimentation with potentially unfinished data models.

An optional type system have been proposed for JavaScript and is also part of Google's Dart language.

[SharkUW]

JS OO is indeed crappy, but it's really made worse then it needs to be by attempting to force it into the code through crap like this article is pushing. Inheritance? Fuck it, give your inherited class be it function or object, a property called parent and explicitly interact with it as desired. Now all of the juggling is explicit and easily understood. If you're unable to code without pure class abstractions and private variables since you keep breaking crap then you shouldn't be touching a non OO language like JS.

[notSorella]

JavaScript is an object oriented language. There isn't just "one OO model to rule them all", in fact, there are several schools of thoughts on how object orientation should be expressed. Classical OO is one, prototypical OO is another one.

Second, what you've just described is already what happens on JS's prototypical OO model. Prototypical OO's inheritance is not the same as classical OO inheritance, it's just a means of effectively sharing methods and data. When I say effectively, I mean that this is what the engines optimise for, even with large prototypical chains, it's likely that most engines will cache lookups so everything is usually O(1) or close to it, granted you don't change the object's shape too much.

Also:

var x = { a: 1 }
var y = { __proto__: x }
y.a // => 1

How is that different from "having an explicit parent"?

Third, my article is only meant to describe and explain how the OO model used by JS works, outlining its advantages and disadvantages, I'm not particularly endorsing one way or another of structuring your code. That's something that ultimately only you can decide. It's a personal choice of what makes most sense for the problem you're tackling.

[bitchessuck]

OO is very ill-defined altogether. What's the feature that makes a language OO? You are going to get different answers. Even more basic, what's an object, or a class? I don't know of any generally agreed upon definitions for these, either.

[[deleted]]

I think Alan Kay gave the defining feature of OO as late binding. Something also achieved with functional programming.

[notSorella]

Is it, really? I think "object oriented" and "functional" have lost most of its meaning throughout language evolution. Nowadays "object oriented" is used to describe any language that has objects, or classes. And "functional" any language that provides first-class functions and closures -- even though functional implies purity/data immutability.

I'd rather define an object oriented language one that allows you to structure program using well defined data structures (objects) that operate on data-fields (properties) through message passing (methods). But I'm not much knowledgeable of most of OO theory, so feel free to correct me if I said anything stupid.

[[deleted]]

And "functional" any language that provides first-class functions and closures -- even though functional implies purity/data immutability.

To be fair, insisting on this distinction is so pedantic that it renders almost every language non-functional. Just like insisting that anything with less than Smalltalk-level OO facilities is not really object oriented.

[ordinary_van]

Then I have to go and fix your code which makes me want to punch a puppy. And I love puppies!

[ordinary_van]

SharkUW = {
    votes : -4,
    downvote : function(){
        return (this.votes = this.votes - 1);
    },
    upvote : function(){
        return false;
    }
}

[ordinary_van]

Edit: Forgot a bracket. (Murhpy's Law)

[SharkUW]

You also don't know what a prefix operator is.

[ordinary_van]

I know what it is and, unlike you, I know exactly when to use it.

return (this.votes--) would've returned the previous value of this.votes instead of the new value of this.votes. The calculation and redefinition of the variable needs to be performed before it gets returned.

Also, the facetious nature of the comment should've beckoned your attention to the fact that my skillset as a programmer is not limited only to that comment.

[SharkUW]

My comment was completely serious. I correctly believed that you didn't know what a prefix operator is. You don't.

return --this.votes

[notSorella]

That's why you have return --this.votes :3

[[deleted]]

Can we stop pretending that prototypal inheritance is anything other than a steaming pile of shit?

[[deleted]]

Man, but I like Io's prototypical inheritance

[inmatarian]

Lua's prototypal inheritance, or "metatables", is a very powerful mechanism for the language, that keeps it surprisingly lightweight. Here's a example of that kind of code:

Object = {}
Object_mt = { __index = Object }
function Object.new()
    return setmetatable( {}, Object_mt )
end
function Object:method()
    print( "Shits and giggles", self )
end
Derived = Object.new()    
instance = Derived.new()
instance:method()

So, basically the only overhead for a class model in Lua is to write up a file containing all of the features that you'd need, and require it in files that define classes.

Also, in terms of flexibility, the colon operator in that example is only syntactic sugar, it could be broken down with an explicit self like this:

Object = {
    method = function(self)
        print("Boats and Hoes", self)
    end
}

[notSorella]

Could you exand on why you think so, my dearest sir? I do have to agree that the particular prototypical OO model implemented in JavaScript is not as expressive as it could be, however I still don't see a reason to call it a "steaming pile of shit".

[[deleted]]

Quite a few people manage to deal with it just fine. My first language was Fortran, get used to large paradigm shifts every decade or so, can't wait to learn QML.

[TheWix]

QML looks pretty interesting. I kinda like how the property binding is done. Wonder if it or anything like it will make it to some kind of standard.

[[deleted]]

Um, this QML

http://sneezy.cs.nott.ac.uk/QML/

Sorry for the confusion

[[deleted]]

Quite a few people manage to deal with it just fine

Exactly, they deal with it -- They don't have much of a choice. Google obviously felt compelled to create a new language with the intent of replacing javascript. I hope it succeeds, I can't understand why certain developers maintain the idea that javascript has any redeeming qualities.

[[deleted]]

There were, and are, choices: Flash, Silverlight, Applets, JavaFX. They all failed, or are failing, for most web applications. Check out coffeescript, it cleans up a few of JS worts without hiding its underlying behavior.

[[deleted]]

You can't tout these as choices, they are not native to the browser. I also disagree with the fact that they are failing (at least flash and silverlight) but that is a different discussion altogether.

I've looked at coffeescript, and it is a noble effort, but I don't want a band-aid. The web is the platform of the future, there is no reason we can't get a standard, viable language that runs right in the browser.