Notes from the Eric Elliott talk from OReilly Fluent conference.

gistfile1.js

/*
Notes from Eric Elliott's talk at the fluent conference
JavaScript has FREEDOM.

In classical inheritance you have tight coupling brought on by the parent-child relationship. This is good in some areas but as the project grows, making changes to the parent that ripple through the descendants can be a big burden and error/bug prone. Thus, the need for duplication by necessity. This is the situation where you have a class that does almost everything you want but it needs to do something a little differently so you create a very identical class for your new need. This is caused by the gorilla banana problem. Where you want a banana but what you got was a gorilla holding the banana and the entire jungle. The problem with object-oriented languages is they've got all this implicit environment that they carry around with them.

JavaScript has inheritance that does not have these problems.

"Program to an interface, not an implementation."
"Favor object composition over class inheritance."
-Gang of Four

In JavaScript there is no class.

What is a prototype? It is a working sample.. that's it.

Three types of prototype:

*/

/*
1. Delegate prototype - when you can't find the mehtod you are looking for you look for it in the prototype; you are delegating this happen. This makes flyweights free.
*/

//old way
function Greeter(name){
    this.name = name || 'John Doe';
}
Greeter.prototype.hello = function hello(){
    return 'Hello, my nam is ' + this.name;
}
var george = new Greeter('George');
/*
we create a constructor, attach a method to its prototype, then instantiate an object with the new keyword. This is weird because you don't need the new keyword in javascript because you can just create an object literal and there you have your object. And the whole constructor business seems to be there to please the people who are used to the constructor style of doing things
*/

//new way
//proposed by Douglas Crockford
var proto = {
    hello : function hello(){
        return 'Hello, my nam is ' + this.name;
    }
};
var george = Object.create(proto);
george.name = 'George';
/*
create the prototype object, pass that prototype to Object.create() and there is your new object. You can now set any property you want on that object because JavaScript has dynamic object extending abilities.
*/



/* 
2. Cloning / Concatenation - creating a new object from all of the copied properties. Used a lot for default state or mixins
*/

//mixin style
var proto = {
    hello : function hello(){
        return 'Hello, my nam is ' + this.name;
    }
};
var george = _.extend({}, proto, { name : 'George'});
/*
Create your prototype (this is where you can set like your default state for things), and then use a utility function like $.extend(obj1, obj2, ...objN); - These usually copy all of the methods and properties of the object to the right of the first object into the first object. Going in left to right order, this provides sort of overriding.
*/

/* 

3. Functional Inheritance - this is not really functional or a prototype. But you can use it in conjunction with prototypal inheritance to create really rich functional objects.
These are good for data incapsulation and privacy
*/

var model = function(){
    var attrs = {};
    this.set = function(name, value){
        attrs[name] = value;
        //do somthing
        //we are in a closure scope so we have access to
    };
    
    //.. any mehtod you add in this lexical scope will have access to the
    //private variables because of closure
    
    _.extend(this, {foo: "bar"}, Backbone.Events /*, [andSoOn...] */);
};

var george = {};
model.call(george).set("name", "George");
/*
Create your model "Function" prototype. This function creates a closure and your var attrs will be private to the mehtods defined in this scope. The model.call(george) basically says, call the model function with the context of george - then you will have the ability to use the methods in this new object.
*/

/*
No one type of prototype will replace classes. But combined, they are very powerful! 

The problem is there is a lot of hoops to jump through to get there; this is cause for much of the demand for the class "sugar." This goes along with the idea tha prototypal inheritance is cool, fun, intuitive, but it could be easier.

One solution is to use factory functions.

Like constructors, when called they spit out a new object. But unlike them, you don't need new or this.
You can mix and match all three types of prototypes.
Use .call() and .apply() to swap out the source of prototypes at instantiation time.

Classes deal with the idea of an object.

-----

Prototypes deal with the object themselves


*/