> Most of you misses the point, it is sadly. Why it is preferred to have
> shorter code (as long it does not add any complexity) is it because it will
> make it easier to understand what is happening. That is the largest
> difference between a low level programming language and a high level
> programming language. It is the same thing when anyone type 1+1. It is
> indeed an abstraction and how it is implemented underneath can we just
> ignore.

> In my opinion it is indeed better to group methods close to each other. My
> helper does not add any direct complexity and no "context" is lost, as long
> we know what we helper does as we do. However it has some advantages:

> - It forces the user to write code which can easily be highly optimized by
> the JavaScript engine. All class methods will be defined in the prototype
> and all variables be bound to the object context. No need to be a good Java
> Script programmer.

> - It can take multiple other compile options, so we can example add cache
> options, so the helper automatically set up a cache for some methods,
> specially deterministic methods. Multiple inheritance can probably also be
> properly implemented, so the instanceof operator will work as it can be
> expected, which in that case would be better to use than most mixins.

> You most remember that if you create a mixin and when assign 10 different
> prototypes a set of methods (using a mixin) will the JavaScript engine have
> very hard to optimize it. What you do is actually indeed multiple
> inheritance, but you are not telling the JavaScript engine about it. If you
> would, would it probably give better performance, both in speed and memory
> consumption.

> You does also a terrible mistake, even if an object has a set of methods,
> does it not mean it implements those methods in that way you may believe.
> The only properly way to actually check this is to use the instanceof
> operator. It would be most safe and probably the fastest way to check this.

> tjholowaychuk:

> I assume when you taking about C++ ambiguous invocation you mean operator
> overloading? A line like: "a = b + c" may invoke several functions. In that
> case can I tell you it is a huge benefit to the language and is there to
> make it easier to human to read, as long it is properly overloaded.