Caimi: Dolby: i am tempted to add a function in foo “factory” : function fooa, b, c{ return { title: a, ISBN: b, author: c, toString:function{console.log”Author: ” + author; }}

Dettmering: Dolby: does that work?

Correo: Tumulty: A fully client side webapp is in no way harder to test. You still test individual units.

Delille: Sl33k: again, you can do anything. It doesn’t matter how you construct objects.

Navorro: Alright. I’ll keep to function Cl***Name. { /* constructor stuff */ }; and prototype, then.

Lusk: Dolby: lol. i cant believe I would want objects without some form of behaviour

Defide: Sl33k: the only difference here is that, between function foo{ return { toString: function { . } } } and var a = { toString: function{ . } }; var b = Object.createa, is that in the first case you’re creating a unique toString function for each object, and in the second there’s only one toString function, which is shared between all

Bidle: You already have objects sl33k

Bidle: Everything is objects

Ferren: Sl33k: for the person *USING* that object, it’s irrelevant. They can’t even *tell* the difference. The only difference here is 1 how long it takes to create new objects; 2 how much memory new allocations take.

Mcthige: Dolby: if javascript was calculating a hash of method deifinition, it should know that those functions are the same anyway

Newburn: Sl33k: I recommend reading this: https://gist.github.com/robotlolita/8adbe91a54e5ce3b49e4. It’s for a different programming language one I designed for work, but it has a very similar OO model for JS

Sarabando: Sl33k: functions are objects. Even if they *do* the same thing, they can differ.

Chyle: Dolby: i’m also glad that “prototype” doesnt come up with above example

Badal: Just like any other object.

Herre: Function a{ return 1 }; function b{ return 1 }; a, b

Jergens: Those function do the same thing, should the VM just merge them into one?

Felicia: Not “do”, i was talking about definition

Sisco: Dolby: this is the link you shared on prototypes right? http://robotlolita.me/2011/10/09/understanding-javascript-oop.html

Marash: Sl33k: that’s an article about JS’s OO model. I don’t remember sharing it today, but I might have since I wrote it.

Shor: Dolby: you shared a link for me to understand prototypes

Stazenski: Sl33k: if I have function foo{ return 1 }, when I call foo, do I get the same array, or different ones?

Brechner: Dolby: you should have different ones ideally!

Jannetti: Sl33k: the one I shared above is part of a book on the language I designed for work. And it might be easier to follow, since the language is simpler/doesn’t have things like constructors and new.

Mathisen: Sl33k: yes. So, likewise, if you have function foo{ return { toString: function{ . }}}, you’ll get different toString functions every time you call foo

Buzzi: I wonder how many languages I know

Buzzi: The only programming lang book I ever read to learn a language was a C book when I had never done any programming before :p

Helvik: Why in this example is sum NaN when the expression directly inside the console log returns a float? http://pastebin.com/smhZEnRW

Bidle: Testerbit: they both look like they do different things

Bidle: Without seeing your datastructure how can we tell

Borsh: Bidle, var a = “lead”,”1″,”snow”,”3″ – that is the structure

Munnell: Bidle, could be a problem with variable ***ignment? var sum = ?

Macmurray: If you add one more value it’ll break

Bidle: You want testerbit not me

Derienzo: Soteros, why is that?

Bidle: I just told them it works for their data structure, not that it’s a good idea :v

Bidle: They may want to look into the docs for reduce

Bucholz: Because in reduce the first argument is what it just returned