methods created when creating new object should be in prototype chain not in object itself

[sk16]

methods created when creating new object should be in prototype chain not in object itself.

Since functions/method itself an object , it memory for it , when creating a object.

var que = new buckets.Queue();

que object is created , and method like enqueue and dequeue is also created in object itself , not in prototype chain.

If I create a hundreds of object like this. It will take a lot of memory .

[sk16]

If possible , I can do necessary changes and will give PR .

[mauriciosantos]

Hello SK16,

This is an intentional design decision. I actually used the the prototype chain for method definitions before and then I changed it this commit when I separated the code into multiple files and added a build system.

I felt that using the prototype chain for defining methods was abusing the prototype pattern too much by trying to make it look like classical languages. I find that using closures makes the code more elegant, increases readability and more importantly it can enforce access control and provides better encapsulation. Everything defined in the prototype will be public to every one else. This is not the case for closures. Another problem with prototypal inheritance is that you can change the prototype AFTER the object was created, so by changing a prototype object you could potentially modify the behavior of millions of objects at once.

I recommend this video which discusses javascript object creational patterns among many other good things.

Memory usage does indeed increase by using this pattern but I don't think it is significant unless you create millions and millions of objects. I might be wrong. I'll be interested in seeing some memory benchmarks if you have them.

[sk16]

was just going through mozilla document . Link : https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures#Performance_considerations

It says " It is unwise to unnecessarily create functions within other functions if closures are not needed for a particular task, as it will negatively affect script performance both in terms of processing speed and memory consumption" .

[serramatutu]

I think adding it to the prototype chain would be a cool feature, mainly because of instanceof tests and for extension methods.

This could be used to make conversion methods such as objectToMultiDictionary, for example, which could receive either a MultiDictionary or an Object and could convert it accordingly to a MultiDictionary. Then, a method which receives, a MultiDictionary can be more flexible, allowing for some syntatic sugar in the caller's side, such as:

function objectToMultiDictionary(o) {
  if (o instanceof buckets.MultiDictionary)
    return o;
  
  for (var prop in o) {
    // blah blah
  }
}

function iLikeMultiDictionaries(d) {
  d = objectToMultiDictionary(d);
}

// caller's side
iLikeMultiDictionaries({
  foo: ['bar', 1, 2, 3],
  hey: ['ho', 4, 5, 6]
});

Note that, in the case above, if the user passed a MultiDictionary to the conversion function, as the instanceof operator doesn't work, the method would proceed to copy all of the passed dictionary's properties to the returned object, which would end up being incorrect.

Finally, it would be cool if it were possible to extend a prototype to add your own methods without having to recompile the source code.

Hope I've added something to the discussion :)