We Keep Coding

javascript real prototype object oriented programming

I have always been fascinated by the notion of "prototype" in javascript, and I have used that to model business domains. But I have not used javascript for actual programming until quite recently. So now I am wondering how to really make use thinking in prototypes rather than classes. Recently javascript gained syntactic sugar with class ... extends { constructor() { ... } ... } and all that stuff that makes javascript appear more like Java. But it detracts away from the prototype orientation.
My question is, if my following intuitions jive and what I should read on if I am not interested in just reproducing Java in the browser (got decades of Java under my belt) but rather, how to really use the prototype paradigm.
First thing that I have always admired but never understood is why a class in javascript is implemented as a function?
> new (function(x) { this.foo = x; })(99)
< { foo: 99 }
It is so cool, but why is that? What's the deep philosophy behind calling new on a function, and effectively saying "a class is nothing but a constructor function". What if I call this function without new? Then this is whatever global object and it really doesn't make sense to add foo onto this, or does it? I bet it makes profound sense, but I just don't understand it.
Next there is the question whether I can build a system without ever calling constructors. This is where the prototype oriented programming comes along, which I apply to real business object modeling.
For example, I have a plan for a car,
car = {
type: "sedan",
material: "aluminum"
}
which essentially is a model of the car, that is, there is some mapping between the model and a real car. Let's say my plan says it has an aluminum body, then any real world instance of this car also has an aluminum body.
myCar = { plate: "FR-AS-2345" }
myCar.__proto__ = car
so now I can query:
> myCar.plate
< 'FR-AS-2345'
> myCar.type
< 'sedan'
Philosophically, what is a "real car" with respect to an information system anyway? Whether we describe the class of aluminum sedans or my car that's parked just outside, there is always a mapping of real world to information structure. And so, the structure of these car models are no different whether I define a universal aluminum sedan or my particular car.
Where this is really neat is in specification refinement. For example, I can say:
redCar = { color: "red" }
redCar.__proto__ = car
And if my car is actually red:
myCar.__proto__ = redCar
But I could also do something even cooler:
carsLikeMine = { plate = undefined }
carsLikeMine.__proto__ = myCar
so I was able to create a "class" from an instance, saying "just like mine but (of course) with an undefined license plate.
You get the gist. I could use
myCar.__proto__ = redCar
but I could also say
Object.setPrototypeOf(myCar, redCar)
which should I use?
And isn't there some easier way to do that? I was hoping I could somehow use the new operator:
yourCar = new carsLikeMine
but of course that doesn't work. However, I am sitting here pondering why not? I know formally the object is not a "constructor" function which new expects (what makes functions a "constructor" anyway, as I can apply the new operator on any function?) But why should there not be a simple operator some notation where I could say:
yourCar = new extend(carsLikeMine, { plate: "TÜ-PS-1234" })
Oh, so I can make my own prototype inheritance function:
function extend(prototype, object) {
// perhaps better also clone object first to prevent side-effect
const newObject = {}
Object.assign(newObject);
newObject.__proto__ = prototype;
return newObject;
}
Why am I the only one making such an extend function? Someone else must have long done this? This whole world of prototype oriented programming must have been explored and charted with all the "no entry" signs posted long ago. What should I read to get on top of that?
And finally, notice that in this prototype approach we do not call "constructors", so any programming that relies on constructors to create valid initialized objects is gone. Should I be concerned about this, or should one just learn to program without relying on constructors? (They are anyway unreliable, because javascript inherently does not protect its objects from change (and neither does Java once you learn to use reflection, I have set private variables on Java objects before).

Do we change states when setting new values in weakmaps?

Suppose we've the following code:
const _timeStamp = new WeakMap();
const _running = new WeakMap();
export class Stopwatch {
constructor() {
_timeStamp.set(this, 0);
_running.set(this, false);
}
start() {
// start stopwatch
_running.set(this, true)
_timeStamp.set(this, Date.now())
}
stop() {
// stop stopwatch
_running.set(this, false);
return (Date.now() - _timeStamp.get(this))/1000
}
}
In this example we're trying to hide some information from the end-user using weakmaps.
Depending on which method is called, we change the values in both weakmaps.
When we reassign variables, we change states.
let x = 0;
x = 10
EDIT:
As a best practice we shouldn't mutate objects or change states in JS
However, don't we change states when updating values in weakmaps like as we do in case of variables? What's the 'best practice' when using private props that need to be rewritable?
Any clarification is well appreciated!

To answer your question about WeakMaps, I think you are talking about side effects. When using a WeakMap you can imagine that there is no userland side effect to setting a value because WeakMaps invert the usual relationship between item and collection. In a WeakMap, for reasons of garbage collection, the item maintains a hidden link to the collection (rather than the collection maintaining a reference to the item), so we can pretend there is no side-effect.
But, this question is also about privacy in JavaScript.
As it happens, JavaScript has always supplied an outstanding (and impenetrable as far as I know - unlike private fields in languages like C#) mechanism for robust privacy: closures. It's just that most developers come from a class-based object-orientation background and take time to learn the "JavaScript way".
That said, syntax for marking fields on classes as private is currently at Stage 3 of the feature development process, and is supported by transpilers.
So the answer is: there are multiple ways to ensure privacy, depending on the precise use case and the style of code your team is using.
Teams using classes will probably use the # private class field syntax.
class MyClass {
#myPrivateField = 'foo'
bar(s) {
return this.#myPrivateField + s
}
}
Teams using functions will use closures.
function createObject() {
let myPrivateVariable = 'foo'
return {
bar(s) {
return myPrivateField + s
}
}
}
You can nit-pick this and say that the function-object for bar is created on a per-instance basis. In the vast majority of cases this won't matter.
Symbols will sometimes be used, although these offer lesser privacy because they can be viewed by reflection.
function createObject() {
let secretSymbol = Symbol('secret')
return ({
[secretSymbol]: 'foo',
bar(s) {
return this[secretSymbol] + s
}
})
}
WeakMaps and modules can also be used. For more details see the links below.
Note that you could also use a class with a closure to ensure a variable remained private.
See also, and.

Does Chrome retain each object's constructor?

In Chrome's JavaScript console:
> function create(proto) {
function Created() {}
Created.prototype = proto
return new Created
}
undefined
> cc = create()
Created {}
> cc
Created {}
Created is a function private to the create function; after create completes, there are no (known to me) references to Created. Yet Chrome can show the function's name at any time, starting from the object created by it.
Chrome didn't achieve this by following the "naïve" approach:
> cc.constructor
function Object() { [native code] }
> cc.toString()
"object [Object]"
and anyway, I didn't set constructor on the proto argument passed to create:
> cc.__proto__.hasOwnProperty("constructor")
false
One guess I had is that the JavaScript VM holds on to Created for the sake of the instanceof mechanism. It is said that instanceof
tests whether an object has in its prototype chain the prototype property of a constructor.
But in the above code I typed create(), effectively passing undefined as prototype; consequently Created doesn't even have its prototype set to the actual cc.__proto__. We can verify this if we hack create to expose the Created function:
function create(proto) {
function Created() {}
Created.prototype = proto
GlobalCreated = Created
return new Created
}
now let's type
> cc = create()
Created {}
> GlobalCreated
function Created() {}
> GlobalCreated.prototype
undefined
> cc instanceof GlobalCreated
TypeError: Function has non-object prototype 'undefined' in instanceof check
My questions (all closely related):
What exactly does Chrome's JavaScript engine retain to make that object presentation in the console work? Is it the constructor function, or just the function name?
Is that retention needed for anything more substantial than console printout?
What is the effect of such retention on memory consumption? What if, for example, the constructor function (or even its name) is abnormally huge?
Is it just Chrome? I've retested with Firebug and Safari, their consoles don't present the object that way. But do they still retain the same data, for other possible purposes (e.g. due to a genuine concern inherent to a JavaScript VM)?

Late edit:
I recently revisited this question/answer, and I think I've figured out why chrome seems to "hang on" to the Created name. It's not really something that is exclusive to V8, but I think it's the result of how V8 works behind the scenes (the hidden objects I explained in my initial answer), and what V8 is required to do (to conform to the ECMAScript standard).
Any function, constructor functions or otherwise, share the same constructor and prototype-chain by default:
function Created(){};
console.log(Created.constructor);//function Function() { [native code] }
console.log(Object.getPrototypeOf(Created));//function Empty() {}
console.log(Created.__proto__);//same as above
console.log(Created.prototype);//Created {}
This tells us a few things: All functions share the native Function constructor, and inherit from a specific function instance (function Empty(){}) that is used as their prototype. However, a function's prototype property is required to be an object, that the function would return if it were called as a constructor (see ECMAScript standard).
The value of the prototype property is used to initialise the [[Prototype]] internal property of a newly created object before the Function object is invoked as a constructor for that newly created object. This property has the attribute { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: false }.
We can verify this easily by looking at the Created.prototype.constructor:
console.log(Created.prototype.constructor);//function Created() {}
Now let's, for a moment, list the hidden classes V8 needs to, and probably will, create in order for it to comply to the standard:
function Created(){}
Hidden classes:
Object, of course: the mother of all objects, of which Function is a specific child
Function: This native object is, as we've demonstrated, the constructor
function Empty: The prototype, from which our function will inherit
Created our empty function that will inherit from all of the above
At this stage, nothing unusual has happened, and it's self-evident that, when we return an instance of this Created constructor, the Created function will get exposed because of its prototype.
Now, because we're reassigning the prototype property you could argue that this instance will be discarded, and is lost, but from what I understand, that's not how V8 will handle this situation. Instead, it'll create an additional hidden class, that simply overrides the prototype property of its parent after this statement is encountered:
Created.prototype = proto;
Its internal structure will end up looking something like this (numbered this time, because I'll refer back to certain stages within this inheritance chain further down):
Object, of course: the mother of all objects, of which Function is a specific child
Function: This native object is, as we've demonstrated, the constructor
function Empty: The prototype, from which our function will inherit
Created our empty function that will inherit from all of the above
Created2: extends the previous class (Created), and overrides prototype
So why is Created still visible?
That's the million dollar question, to which I think I have the answer now: Optimization
V8 simply can't, nor should it be allowed to, optimize out the Created hidden class (stage 4). Why? Because what will override prototype is an argument. It's something that can't be predicted. What V8 will probably do to optimize the code is to store a hidden object 4, and whenever the create function is called, it'll create a new hidden class that extends stage 4, overriding the prototype property with whatever value is passed to the function.
Because of this, Created.prototype will always exist somewhere inside each instance's internal representation. It's also important to note you could replace the prototype property with one that actually referenced an instance of Created (with a mucked-up prototype chain, but still):
cc = create();
console.log(Object.getPrototypeOf(cc))//Object {}
cc = create(new GlobalCreated);
console.log(Object.getPrototypeOf(cc));//Created {}
How's that for a mind-bender? Inception script-writers, eat your hearts out...
Anyway, I hope all of this dribble made some sense to someone out here, if not, I do respond to comments, so corrections to mistakes I may have made, or questions regarding some part of this update that is a bit unclear are welcome...
I'll try to answer question by question, but as you say, they're all closely related, so the answers overlap up to a point.
While reading this, bare in mind that I wrote this in one go, whilst feeling a bit feverish. I am not a V8 expert, and based this on recollections of my doing some digging in the V8 internals some time ago. The link at the bottom is to the official docs, and will of course contain more accurate and up-to-date information on the subject.
What is going on
What chrome's V8 engine actually does is create a hidden class for each object, and this class is mapped to the JS representation of the object.
Or as the people at google say so themselves:
To reduce the time required to access JavaScript properties, V8 does not use dynamic lookup to access properties. Instead, V8 dynamically creates hidden classes behind the scenes.
What happens in your case, extending, creating a new constructor from a particular instance and overriding the constructor property is actually nothing more than what you can see on this graph:
Where hidden class C0 could be regarded as the standard Object class. Basically, V8 interprets your code, builds a set of C++ like classes, and creates an instance if needed. The JS objects you have are set to point to the different instances whenever you change/add a property.
In your create function, this is -very likely- what is going on:
function create(proto)
{//^ creates a new instance of the Function class -> cf 1 in list below
function Created(){};//<- new instance of Created hidden class, which extends Function cf 2
function Created.prototype = proto;//<- assigns property to Created instance
return new Created;//<- create new instance, cf 3 for details
}
Right: Function is a native construct. The way V8 works means that there is a Function class that is referenced by all functions. They reference this class indirectly, though, because each function has its own specifcs, which are specified in a derived hidden class. create, then, should be seen as a reference to create extends HiddenFunction class.
Or, if you wish, in C++ syntax: class create : public Hidden::Function{/*specifics here*/}
The Create function references a hidden function identical to create. However, after declaring it, the class receives 1 propriety property, called prototype, so another hidden class is created, specifying this property. This is the basis of your constructor. Because the function body of create, where all of this happens, this is a given, and V8 will probably be clever enough to create these classes beforehand, anyway: in C++ pseudo-code, it'll look similar to code listing 1 below.
Each function call will assign a reference to a new instance Of the hidden class described above, to the Created name, which is local to create's scope. Of course, the returned instance of create does still retain the reference to this instance, but that's how JS scopes work, and so this applies to all engines... think of closures and you'll get what I mean (I'm really struggling with this nasty fever... sorry to nag about this)
At this stage Create points to an instance of this hidden class, which extends a class that extends a class (as I tried to explain in point 2). Using the new keyword triggers behaviour defined by the Function class, of course (as it's a JS language construct). This results in a hidden class to be created which is probably the same for all instances: it extends the native object, and this has a constructor property, which references the instance of Created we've just made. The instances returned by create though are all alike. Sure their constructors may have a different prototype property, but the objects they churn out all look the same. I'm fairly confident that V8 will only create 1 hidden class for the objects create returns. I can't see why the instances should require different hidden classes: their property names & count are the same, but each instance references another instance, but that's what classes are for
Anyway: code listing for item 2, a pseudo-code representation of what Created might look like in hidden-class terms:
//What a basic Function implementation might look like
namespace Hidden
{//"native" JS types
class Function : public Object
{
//implement new keyword for constructors, differs from Object
public:
Function(...);//constructor, function body etc...
Object * operator new ( const Function &);//JS references are more like pointers
int length;//functions have a magic length property
std::string name;
}
}
namespace Script
{//here we create classes for current script
class H_create : public Hidden::Function
{};
class H_Created : public Hidden::Function
{};//just a function
class H_Created_with_prototype : public H_Created
{//after declaring/creating a Created function, we add a property
//so V8 will create a hidden class. Optimizations may result in this class
// being the only one created, leaving out the H_Created class
public:
Hidden::Object prototype;
}
class H_create_returnVal : public Hidden::Object
{
public:
//the constructor receives the instance used as constructor
//which may be different for each instance of this value
H_create_returnVal(H_Created_with_prototype &use_proto);
}
}
Ignore any (likely) syntax oddities (it's been over a year since I wrote a line of C++), and ignoring namespaces and wacky names, The listed classes are, apart from the Hidden::Function effectively all the hidden classes that will ever need to be created to run your code. All your code then does is assign references to instances of these classes. The classes themselves don't take up much space in memory. And any other engine will create just as many objects, because they, too, need to comply with the ECMAScript specs.
So I guess, looking at it like this, this sort of answers all your questions: no not all engines work like this, but this approach won't cause massive amounts of memory to be used, Yes, this does mean a lot of information/data/references to all objects is retained, but that's just an unavoidable, and in some cases happy side-effect of this approach.
Update: I did a bit more digging, and found an example of how you could add JS functions to V8 using templates, it illustrates how V8 translates JS objects/functions to C++ classes, see the example here
This is just me speculating, but I wouldn't at all be surprized to learn that the way V8 works, and this retention business is heavily used in garbage-collection and memory management in general (EG: deleting a property changing hidden classes and the like)
For example:
var foo = {};//foo points to hidden class Object instance (call id C0)
foo.bar = 123;//foo points to child of Object, which has a property bar (C1)
foo.zar = 'new';//foo points to child of C1, with property zar (C2)
delete foo.zar;//C2 level is no longer required, foo points to C1 again
That last bit is just me guessing, but it could be possible for the GC to do this.
What is this retention used for
As I said, in V8, a JS object is actually a sort-of pointer to a C++ class. Accessing properties (and this includes the magic properties of arrays, too!), is fast. Really, really fast. In theory, accessing a property is an O(1) operation.
That's why, on IE:
var i,j;
for(i=0,j=arr.length;i<j;++i) arr[i] += j;
Is faster than:
for (i=0;i<arr.length;++i) arr[i] += arr.length;
While on chrome, arr.length is faster as shown her. I also answered that question, and it, too, contains some details on V8 you may want to check. It could be that my answer there doesn't (completely) apply anymore, because browsers and their engines change fast...
What about the memory
Not a big problem. Yes, Chrome can be a bit of resource hog at times, but the JS isn't always to blame. Write clean code, and the memory footprint won't be too different on most browsers.
If you create a huge constructor, then V8 will create a larger hidden class, but if that class specifies a lot of properties already, then chances of their being a need for additional hidden classes is smaller.
And of course, each function is an instance of the Function class. This being a native (and very important) type in a functional language will most likely be a highly optimized class anyway.
Anyway: as far as memory usage is concerned: V8 does a pretty good job managing memory. Far better than IE's of old, for example. So much so that the V8 engine is used for server-side JS (as in node.js), if memory really was an issue, then you wouldn't dream of running V8 on a server that must be up and running as much as possible, now would you?
Is this just Chrome
Yes, in a way. V8 does have a special take on how it consumes and runs JS. Rather than JIT-compiling your code to bytecode and running that, it compiles the AST straight into machine code. Again, like the hidden-classes trickery, this is to increase performance.
I know I included this graph in my answer on CR, but just for completeness' sake: Here's a graph that shows the differences between chrome (bottom) and other JS engines (top)
Notice that below the bytecode instructions and the CPU, there's an (orange) interpreter layer. That's what V8 doesn't need, owing to the JS being translated into machine code directly.
The downside being that this makes certain optimizations harder to do, especially concerning the ones where DOM data and user input is being used in the code (for example: someObject[document.getElementById('inputField').value]) and that the initial processing of the code is harder on the CPU.
The upside is: once the code is compiled into machine code, it's the fastest you're going to get, and running the code is likely to cause less overhead. A bytecode interpreter is heavier on the CPU most of the time, that's why busy loops on FF and IE can cause the browser to alert the user of a "running script" asking them if they want to stop it.
more on V8 internals here

I don't know much about Chrome's internals, so this is just a guess, but it seems to me that Chrome is performing some kind of static analysis on the code which created the function, and storing that for debugging purposes.
Take a look at this example:
> function create(proto) {
object = {}
object.x = {}
x = object.x
x.func = function() {}
x.func.prototype = proto
return new object.x.func
}
undefined
> create()
x.func {}
x.func? There's no way JavaScript has any built-in way for you to access the name of the variable a function was initially assigned to. Chrome must be doing that for its own reasons.
Now look at this example:
> function newFunc() {
return function() {}
}
> function create(proto) {
object = {}
object.x = {}
x = object.x
x.func = newFunc()
x.func.prototype = proto
return new object.x.func
}
undefined
> create()
Object {}
In this example, since we created the function in a separate closure before assigning it to a variable, Chrome doesn't know the "name" of the function, so it just says "Object".
These examples lead me to guess the following answers to your questions:
What exactly does Chrome's JavaScript engine retain to make that object presentation in the console work? Is it the constructor function, or just the function name?
It performs a static analysis of the code, and stores a string containing the function's "name" somewhere.
Is that retention needed for anything more substantial than console printout?
Probably not.
What is the effect of such retention on memory consumption? What if, for example, the constructor function (or even its name) is abnormally huge?
I'm not sure, but I'm guessing it's very unlikely to be an issue. Since the name of the function is determined using static analysis, the potential size of the function name is limited by the size of variable names in the script which created it (unless perhaps you're using eval, in which case I'm not sure).
Is it just Chrome? I've retested with Firebug and Safari, their consoles don't present the object that way. But do they still retain the same data, for other possible purposes (e.g. due to a genuine concern inherent to a JavaScript VM)?
I doubt it, this seems to be something specific to Chrome used to make debugging a bit easier. As far as I can tell, there's no other reason for a feature like this to exist.

Disclaimer: I am not a Google Chrome expert, however I think that these are not browser-specific, and can be explained by basic Javascript rules.
What exactly does Chrome's JavaScript engine retain to make that
object presentation in the console work? Is it the constructor
function, or just the function name?
Each Object or Function in Javascript has its inheritance chain, going up, all the way to the basic prototype.
You can not circumvent this by setting the prototype property to undefined, although it may seem like it from the console output.
So it is the whole constructor function that is retained because of inheritance, although not available to be accessed through global scope.
Is that retention needed for anything more substantial than console
printout?
Yes, it is needed for the prototype inheritance system to work.
What is the effect of such retention on memory consumption? What if,
for example, the constructor function (or even its name) is abnormally
huge?
Yes, this can cause a memory leak if used improperly.
This is why you should always delete and clean unused variables, so these and their prototypes can get collected by the garbage collector.
Is it just Chrome? I've retested with Firebug and Safari, their
consoles don't present the object that way. But do they still retain
the same data, for other possible purposes (e.g. due to a genuine
concern inherent to a JavaScript VM)?
This should work the same way across all browsers, because prototypal inheritance works the same. I have however not specifically tested for it. Please note that the console outputs int browsers can differ, and this does not mean anything, as each browser can implement its console in its own way.

//The real method to do clone
function doClone(source, keys, values, result) {
if (source == null || typeof (source) !== "object") {
return source;
}
if (source.Clone instanceof Function) {
return source.Clone();
}
if (source instanceof Date) {
if (!(result instanceof Date)) {
result = new Date();
}
result.setTime(source.getTime());
return result;
}
else if (source instanceof Array) {
if (!(result instanceof Array)) {
result = [];
}
for (var i = 0; i < source.length; i++) {
result[i] = clone(source[i], keys, values, result[i]);
}
return result;
}
try {
if (typeof result !== "object" || result == null) {
result = new source.constructor();
} else {
result.constructor = source.constructor;
}
if (source.prototype) {
result.prototype = source.prototype;
}
if (source.__proto__) {
result.__proto__ = source.__proto__;
}
} catch (e) {
if (Object.create) {
result = Object.create(source.constructor.prototype);
} else {
result = {};
}
}
if (result != null) {
// ReSharper disable once MissingHasOwnPropertyInForeach
for (var property in source) {
if (source.hasOwnProperty(property)) {
try {
var descriptor = Object.getOwnPropertyDescriptor(source, property);
if (descriptor != null) {
if (descriptor.get || descriptor.set) {
Object.defineProperty(result, property, descriptor);
} else {
descriptor.value = clone(descriptor.value, keys, values, result[property]);
Object.defineProperty(result, property, descriptor);
}
} else {
result[property] = clone(source[property], keys, values, result[property]);
}
} catch (e) {
result[property] = clone(source[property], keys, values, result[property]);
}
}
}
}
return result;
}
//The portal of clone method
function clone(source, keys, values, result) {
var index = keys.indexOf(source);
if (index !== -1) {
return values[index];
}
result = doClone(source, keys, values, result);
index = keys.indexOf(source);
if (index !== -1) {
values[index] = result;
} else {
keys.push(source);
values.push(result);
}
return result;
}
/**
* Core functions
*/
var X = {
/**
* Clone indicated source instance
* #param {} source The source instance to be clone
* #param {} target If indicated, copy source instance to target instance.
* #returns {}
*/
Clone: function (source, target) {
return clone(source, [], [], target);
}
}

You return a new instance from create to a object called Created.
create()()
> TypeError: object is not a function
If you were to remove the 'new' keyword, then you would expose the Created function to the caller's scope.

js jquery Prototype functions vs nested functions

I am trying to understand difference between Prototype functions and nested functions.
I Need to know the following
Which is better , performance wise
What is the main difference between the two
Which structure is better suited for which situations (I assume both have different aim) ?
My Basic usage :
My basic usage is I want to write a a main function for web app that when initiated, it will created menus, buttons , button clicks events, draw charts,make tables etc. during app navigation and i need my code to be structured in a better and fastest way. And I will be using jquery and its plugins alot *.
For simplicity of usage , consider I need to create portlets/widget container at many places/stages in may app, and I would just call var port = App.creatPortlet() and then port.content(// place data)
Kindly Help.
Performance:
I created performance test here prototype-vs-nested-function and it seems PROTOTYPE function is faster. But I need some advice on it.
PROTOTYPE FUNCTION:
function Person(opt) {
this.firstName = opt.firstName;
this.lastName = opt.lastName;
}
Person.prototype.getFullName = function() {
return this.firstName + " " + this.lastName;
};
// Testing performance
var P1 = new Person({
firstName: 'Jeremy',
lastName: 'McPeak'
}).getFullName();
NESTED FUNCTION:
var Person = function(opt) {
return {
getFullName: function() {
return opt.firstName + " " + opt.lastName;
}
};
}
// Testing performance
var P1 = new Person({
firstName: 'Jeremy',
lastName: 'McPeak'
}).getFullName();
UPDATE:
http://jsperf.com/closure-prototype-static-reveal
I created benchamrk according to my exact need.

Well first of all performance tests for such small portions of code are not really useful because you don't know if this will reflect the performance in real use case scenario.
(It could happen that you test the optimizer of the JS engine for that small code, e.g. inlining of some methods or that you trigger an optimizing process of the JS engine that would take longer to initialize but would bring performance boosts in realtime applications, that you detected a flaw of the testing library, ....)
I bet you don't test prototype vs nested functions here but two assignments vs scope handling.
Looking at your test, you don't even test both cases. You just test the case two (In your preparation you overwrite the access to the name function Person with the var Person = ...;, so function Person is never used in your test). It should look like this: updated jsperf.com.
(EDIT looks like you already changed yourself while i was writing).
Anyway what is the difference and what is better. Well both have valid use cases and it is up to you to determine what is better.
Object Type
For the first one, every object created by Person is of the same type:
var p1 = new Person();
var p2 = new Person();
console.log( p1 instanceof Person); //true
console.log( p2 instanceof Person); //true
While with the second example every object you create is of type Object.
So with he first one you, if the object is passed to another function, you can test if it is of type Person, while for the second one you can't.
While I prefer to test for the existence of a feature/function instead of testing for a type, this would - for me - make no difference.
Prototype chain
Sometimes it is useful to updated/extend functionality for all objects or modify/extend an existing function for all objects of one type.
While this is possible for the first Example it is not possible for the second one.
var Person = function() {
};
var p1 = new Person();
Person.prototype.doSomething = function() {console.log("....");};
p1.doSomething();
Reuse of code
With the first example you can reuse your functions on objects that are similar to the given one. You could do something like this:
Person.prototype.doSomething.call(similarOBject, ...);
Which could be handy in some situations. An example where this is often use are Array functions on array like objects.
Protection of raw data
Sometimes it is useful to protect some raw data from being read/modified directly.
That is that is strength of the second example. While I personally thing this should be handled by a good documentation instead of forcing it by code it is still a valid use case.
In your example firstName and lastName is completely hidden from outside, except for the code part that creates the the Person.
Performance and Speed
Which one performs better in speed and memory usage depends mainly on the JS engine.
Not every engine will create a new function for the nested functions, it is more likely that it is correctly detected and just references on the second call. The scope creation will have some overhead, but this is probably negligible depending on the object count and how frequent you create them.
But as already said you will most likely have other things in your code that will create bottlenecks.
In most of the cases using prototype is the better choice with of respect maintainability and readability.

No ways to have class-based objects in javascript?

The javascript prototype-based object-oriented programming style is interesting, but there are a lot of situations where you need the ability to create objects from a class.
For instance in a vector drawing application, the workspace will usually be empty at the beginning of the drawing : I cannot create a new "line" from an existing one. More generally, every situation where objects are being dynamically created require the use of classes.
I've read a lot of tutorials and the book "Javascript : the good parts", but yet it seems to me that there is no way to define classes that respect 1) encapsulation and 2) efficient member methods declaration (I mean : member methods that are being defined once, and shared among every class instances).
To define private variables, closures are being used :
function ClassA()
{
var value = 1;
this.getValue = function()
{
return value;
}
}
The problem here is that every instance of "ClassA" will have its own copy of the member function "getValue", which is not efficient.
To define member functions efficiently, prototype is being used :
function ClassB()
{
this.value = 1;
}
ClassB.prototype.getValue = function()
{
return this.value;
}
The problem here is that the member variable "value" is public.
I don't think that this issue can be solved easily, since "private" variables need to be defined DURING object creation (so that the object can have access to its context of creation, without exposing thoses values) whereas prototype-based member functions definition has to be done AFTER object creation, so that prototype makes sense ("this.prototype" does not exists, I've checked).
Or am I missing something ?
EDIT :
First of all, thank you for your interesting answers.
I just wanted to add a little precision to my initial message :
What I really want to do is to have 1) private variables (encapsulation is good, because people only have access to what they need) and 2) efficient member methods declaration (avoid copies).
It seems that simple private variables declaration can really only be achieved via closure in javascript, that's essentially why I focused on the class based approach. If there is a way to achieve simple private variables declaration with a prototype based approach, that's okay for me, I'm not a fierce class-based approach proponnent.
After reading the answers, it seems like the simple solution is to forget about privates, and use a special coding conventions to detter other programmers from accessing "private" variables directly...
And I agree, my title / first sentence was misleading regarding the issue I wanted to discuss here.

Shh, come here! Wanna hear a secret?
Classical inheritance is a tested and tried approach.
It is useful to implement it in JavaScript often. Classes are a nice concept to have and having templates for modeling our world after objects is awesome.
Classical inheritance is just a pattern. It's perfectly OK to implement classical inheritance in JavaScript if it's the pattern you need for your use case.
Prototypical inheritance focuses on sharing functionality and that's awesome (dinasaur drumstick awesome), but in some cases you want to share a data-scheme and not functionality. That's a problem prototypical inheritance does not address at all.
So, you're telling me classes are not evil like everyone keeps telling me?
No, they are not. What the JS community frowns upon is not the concept of classes, it's limiting yourself to just classes for code reuse. Just like the language does not enforce strong or static typing, it doesn't enforce schemes on object structure.
In fact, behind the scene clever implementations of the language can turn your normal objects to something resembling classical inheritance classes.
So, how do classes work in JavaScript
Well, you really only need a constructor:
function getVehicle(engine){
return { engine : engine };
}
var v = getVehicle("V6");
v.engine;//v6
We now have a vehicle class. We didn't need to define a Vehicle class explicitly using a special keyword. Now, some people don't like to do things this way and are used to the more classical way. For this JS provides (silly imho) syntactic sugar by doing:
function Vehicle(engine){
this.engine = engine;
}
var v = new Vehicle("V6");
v.engine;//v6
That's the same thing as the example above for the most part.
So, what are we still missing?
Inheritance and private members.
What if I told you basic subtyping is very simple in JavaScript?
JavaScript's notion of typing is different than what we're used to in other languages. What does it mean to be a sub-type of some type in JS?
var a = {x:5};
var b = {x:3,y:3};
Is the type of b a sub type of the type of a? Let's say if it is according to (strong) behavioral subtyping (the LSP):
<<<< Begin technical part
Contravariance of method arguments in the subtype - Is fully preserved in this sort of inheritance.
Covariance of return types in the subtype - Is fully preserved in this sort of inheritance.
No new exceptions should be thrown by methods of the subtype, except where those exceptions are themselves subtypes of exceptions thrown by the methods of the supertype. - Is fully preserved in this sort of inheritance.
Also,
Preconditions cannot be strengthened in a subtype.
Postconditions cannot be weakened in a subtype.
Invariants of the supertype must be preserved in a subtype.
The history rule
All of these are again, are up to us to keep. We can keep them as tightly or loosly as we want, we don't have to, but we surely can.
So matter of fact, as long as we abide to these rules above when implementing our inheritance, we're fully implementing strong behavioral subtyping, which is a very powerful form of subtyping (see note*).
>>>>> End technical part
Trivially, one can also see that structural subtyping holds.
How would this apply to our Car example?
function getCar(typeOfCar){
var v = getVehicle("CarEngine");
v.typeOfCar = typeOfCar;
return v;
}
v = getCar("Honda");
v.typeOfCar;//Honda;
v.engine;//CarEngine
Not too hard, was it? What about private members?
function getVehicle(engine){
var secret = "Hello"
return {
engine : engine,
getSecret : function() {
return secret;
}
};
}
See, secret is a closure variable. It's perfectly "private", it works differently than privates in languages like Java, but it's impossible to access from the outside.
What about having privates in functions?
Ah! That's a great question.
If we want to use a private variable in a function we share on the prototype we need to firrst understand how JS closures and functions work.
In JavaScript functions are first class. This means you can pass functions around.
function getPerson(name){
var greeting = "Hello " + name;
return {
greet : function() {
return greeting;
}
};
}
var a = getPerson("thomasc");
a.greet(); //Hello thomasc
So far so good, but we can pass that function bounded to a around to other objects! This lets you do very loose decoupling which is awesome.
var b = a.greet;
b(); //Hello thomasc
Wait! How did b know the person's name is thomasc? That's just the magic of closures. Pretty awesome huh?
You might be worried about performance. Let me tell you how I learned to stop worrying and started to love the optimizing JIT.
In practice, having copies of functions like that is not a big issue. Functions in javascript are all about well, functionality! Closures are an awesome concept, once you grasp and master them you see it's well worth it, and the performance hit really isn't that meaningful. JS is getting faster every day, don't worry about these sort of performance issues.
If you think it's complicated, the following is also very legitimate. A common contract with other developers simply says "If my variable starts with _ don't touch it, we are both consenting adults". This would look something like:
function getPerson(name){
var greeter = {
greet : function() {
return "Hello" +greeter._name;
}
};
greeter._name = name;
return greeter;
}
Or in classical style
function Person(name){
this._name = name;
this.greet = function(){
return "Hello "+this._name;
}
}
Or if you'd like to cache the function on the prototype instead of instantiate copies:
function Person(name){
this._name = name;
}
Person.prototype.greet = function(){
return "Hello "+this._name;
}
So, to sum it up:
You can use classical inheritance patterns, they are useful for sharing types of data
You should also use prototypical inheritance, it is just as potent, and much more in cases you want to share functionality.
TheifMaster pretty much nailed it. Having privates private is really not a big deal as one might think in JavaScript, as long as your code defines a clear interface this should not be problematic at all. We're all concenting adults here :)
*The clever reader might think: Huh? Weren't you tricking me there with the history rule? I mean, property access isn't encapsulated.
I say no, I was not. Even if you don't explicitly encapsulate the fields as private, you can simply define your contract in a way that does not access them. Often like TheifMaster suggested with _. Also, I think the history rule is not that big of a deal in a lot of such scenarios as long as we're not changing the way property access treats properties of the parent object. Again, it's up to us.

I don't want to be discouraging since you seem to be a fairly new member of StackOverflow, however I'm going to have to be a little in your face and say that it's a really bad idea to try to implement classical inheritance in JavaScript.
Note: When I say that it's a bad idea to implement classical inheritance in JavaScript I mean that trying to simulate actual classes, interfaces, access modifiers, etc. in JavaScript is a bad idea. Nevertheless, classical inheritance as a design pattern in JavaScript is useful as it's just syntactic sugar for prototypal inheritance (e.g. maximally minimal classes). I use this design pattern in my code all the time (a la augment).
JavaScript is a prototypal object-oriented programming language. Not a classical object-oriented programming language. Sure, you can implement classical inheritance on top of JavaScript but before you do keep the following things in mind:
You're going against the spirit of the language, which means that you'll be faced with problems. Lots of problems - performance, readability, maintainability, etc.
You don't need classes. Thomas, I know that you truly believe that you need classes but trust me on this. You don't.
For your sake I'll provide two answers to this question. The first one will show you how to do classical inheritance in JavaScript. The second one (which I recommend) will teach you to embrace prototypal inheritance.
Classical Inheritance in JavaScript
Most programmers start with trying to implement classical inheritance in JavaScript. Even JavaScript Gurus like Douglas Crockford tried to implement classical inheritance in JavaScript. I too tried to implement classical inheritance in JavaScript.
First I created a library called Clockwork and then augment. However I wouldn't recommend you to use either of these libraries because they go against the spirit of JavaScript. The truth is that I was still an amateur JavaScript programmer when I wrote these classical inheritance libraries.
The only reason I mention this is because everyone is an amateur at some point of time, and although I would prefer that you didn't use classical inheritance patterns in JavaScript, I can't expect you to understand why prototypal inheritance matters just yet.
You can't learn how to cycle without falling down a few times. I believe you're still in the learning phase with respect to prototypal inheritance. Your need for classical inheritance is like the training wheels on cycles.
Nevertheless, training wheels are important. If you want there are some classical inheritance libraries out there which should make you more comfortable writing code in JavaScript. One such library is jTypes. Just remember to take off the training wheels when you are confident of your skills as a JavaScript programmer.
Note: Personally I don't like jTypes one bit.
Prototypal Inheritance in JavaScript
I'm writing this section as a milestone for you so that you can come back later and know what to do next when you are ready to learn about true prototypal inheritance.
First of all the following line is wrong:
The javascript prototype-based object-oriented programming style is interesting, but there are a lot of situations where you need the ability to create objects from a class.
This is wrong because:
You will never need to create objects from a class in JavaScript.
There is no way to create a class in JavaScript.
Yes it's possible to simulate classical inheritance in JavaScript. However you're still inheriting properties from objects and not classes. For example, ECMAScript Harmony classes are just syntactic sugar for the classical pattern of prototypal inheritance.
In the same context the example you gave is also wrong:
For instance in a vector drawing application, the workspace will usually be empty at the beginning of the drawing : I cannot create a new "line" from an existing one. More generally, every situation where objects are being dynamically created require the use of classes.
Yes you can create a new line from an existing one even though the workspace is empty in the beginning. What you need to understand is that the line is not actually drawn though.
var line = {
x1: 0,
y1: 0,
x2: 0,
y2: 0,
draw: function () {
// drawing logic
},
create: function (x1, y1, x2, y2) {
var line = Object.create(this);
line.x1 = x1;
line.y1 = y1;
line.x2 = x2;
line.y2 = y2;
return line;
}
};
Now you can draw your the above line by simply calling line.draw or else you could create a new line from it:
var line2 = line.create(0, 0, 0, 100);
var line3 = line.create(0, 100, 100, 100);
var line4 = line.create(100, 100, 100, 0);
var line5 = line.create(100, 0, 0, 0);
line2.draw();
line3.draw();
line4.draw();
line5.draw();
The lines line2, line3, line4 and line5 form a 100x100 square when drawn.
Conclusion
So you see you really don't need classes in JavaScript. Objects are enough. Encapsulation can be easily achieved using functions.
That being said you can't have public functions of each instance access the private state of the object without each instance having its own set of public functions.
This is not a problem however because:
You don't really need private state. You may think that you do, but you really don't.
If you really want to make a variable private then as ThiefMaster mentioned just prefix the variable name with an underscore and tell your users not to mess with it.

Aight, here's my attempt at solving this particular issue, although I think following conventions it's a better approach, ie. prefix your variables with _. Here I just keep track of the instances in an array, they can then be removed with a _destroy method. I'm sure this can be improved but hopefully it will give you some ideas:
var Class = (function ClassModule() {
var private = []; // array of objects of private variables
function Class(value) {
this._init();
this._set('value', value);
}
Class.prototype = {
// create new instance
_init: function() {
this.instance = private.length;
private.push({ instance: this.instance });
},
// get private variable
_get: function(prop) {
return private[this.instance][prop];
},
// set private variable
_set: function(prop, value) {
return private[this.instance][prop] = value;
},
// remove private variables
_destroy: function() {
delete private[this.instance];
},
getValue: function() {
return this._get('value');
}
};
return Class;
}());
var a = new Class('foo');
var b = new Class('baz');
console.log(a.getValue()); //=> foo
console.log(b.getValue()); //=> baz
a._destroy();
console.log(b.getValue()); //=> baz

You don't need private/public at runtime. These are enforceable statically. Any project complex enough to enforce private properties are not used outside will have a build/pre-process step, which you can use
to verify the fact. Even languages with syntax for private/public have a way to access private at runtime.
As for defining class-based objects, the constructor+prototype you are using is the simplest and most efficient way. Any kind of additional wizardry will
be more complex and less performant.
Although you can cache prototype so you don't have to repeat ClassB.prototype. all the time:
//in node.js you can leave the wrapper function out
var ClassB = (function() {
var method = ClassB.prototype;
function ClassB( value ) {
this._value = value;
}
method.getValue = function() {
return this._value;
};
method.setValue = function( value ) {
this._value = value;
};
return ClassB;
})();
The above does not require any library and you can easily create a macro for it.
Also, in this case even a regex is enough to verify
that "private" properties are used correctly. Run /([a-zA-Z$_-][a-zA-Z0-9$_-]*)\._.+/g through the file and see that the first match
is always this. http://jsfiddle.net/7gumy/

It's impossible as far as I know without other instances influencing the value, so if it's a constant you're still good by wrapping it in a function like this:
(function( context ) {
'use strict';
var SOME_CONSTANT = 'Hello World';
var SomeObject = function() {};
SomeObject.prototype.sayHello = function() {
console.log(SOME_CONSTANT);
};
context.SomeObject = SomeObject;
})( this );
var someInstance = new SomeObject();
someInstance.sayHello();
The best you could do is annotate that a property shouldn't be touched by using an underscore like this._value instead of this.value.
Note that private functions are possible by hiding them in a function:
(function( context ) {
'use strict';
var SomeObject = function() {};
var getMessage = function() {
return 'Hello World';
};
SomeObject.prototype.sayHello = function() {
console.log(getMessage());
};
context.SomeObject = SomeObject;
})( this );
var someInstance = new SomeObject();
someInstance.sayHello();
Here is an example of 2 'Classes' extending and interacting with each other: http://jsfiddle.net/TV3H3/

If you really want private entities on a per instance basis, but still want to inherit your methods, you could use the following set-up:
var Bundle = (function(){
var local = {}, constructor = function(){
if ( this instanceof constructor ) {
local[(this.id = constructor.id++)] = {
data: 123
};
}
};
constructor.id = 0;
constructor.prototype.exampleMethod = function(){
return local[this.id].data;
}
return constructor;
})();
Now if you create a new Bundle, the data value is locked away inside:
var a = new Bundle(); console.log( a.exampleMethod() ); /// 123
However you now get into the debate as to whether you should truly have private values in JavaScript. As far as I've found it's always better for those that may need to extend your code—even yourself—to have open access to everything.
There are also hidden downsides to the above pattern, besides not being so readable, or being clunky to access "private" values. One fact is that every single instance of Bundle will retain a reference to the local object. This could mean—for example—if you created thousands of Bundles, and deleted all but one of them, the data held in local would not be garbage collected for all Bundles ever created. You'd have to include some deconstruction code to fix that... basically making things more complicated.
So I'd recommend dropping the idea of private entities / properties, whichever pattern you decide to go for... object-based or constructor. The benefit of JavaScript is that all these different approaches are possible—it's no-where-near as clear cut as class-based languages—which some could argue makes things confusing, but I like the freedom JavaScript lends towards being quick and expressive.

with regards this statement in your question:
For instance in a vector drawing application, the workspace will usually be empty at the beginning of the drawing : I cannot create a new "line" from an existing one. More generally, every situation where objects are being dynamically created require the use of classes.
You seem to be under the misunderstanding that objects in Javascript can only be made by cloning existing objects, which would backtrack to the problem of "okay but what about the very first object? that can't be made by cloning an existing object because there aren't any existing objects."
However you can make objects from scratch, and the syntax for that is as simple as var object = {}
I mean, that's the simplest possible object, an empty object. More useful of course would be an object with stuff in it:
var object = {
name: "Thing",
value: 0,
method: function() {
return true;
}
}
and so on, and now you're off to the races!

There are cleverer people than I answering this question, but I wanted to note one part in particular that you just edited in - the private variable part.
You can simulate this using closures; an awesome construct which allows a function to have it's own environment. You could do this:
var line = (function() {
var length = 0;
return {
setLen : function (newLen) {
length = newLen;
},
getLen : function () {
return length;
}
};
}());
This will set line to be an object with the setLen and getLen methods, but you'll have no way of manually accessing length without using those methods.