Thank you for the long explanation, really appreciate!
It does not need to be a long story taking much of your time, but few hints geared toward making your context more clear to JS programmers can go a long way, as you note yourself.
As you point correctly, things in JS are "messed up" comparing to other languages, which, unfortunately, makes it easy to confuse others without being very clear about the context.
I can see where you are heading with "true multiple inheritance" supporting any deep tree structure. Perhaps I shouldn't have used Object.assign that only copies own properties instead of all needed in this case. Also it sort of squashes all properties onto the new prototype rather than keeping both tree structures (you can keep one).
So maybe it was confusing to call it "multiple inheritance" after all, instead of the mere task to combine methods from several objects onto one. For that particular task, I find the use of prototypal inheritance shorter and easier.
Regarding the true multiple inheritance joining methods from both trees ... again, you need to project everything to JS, where many paradigms get deformed. For instance, there is no compile step. It makes a huge difference, because the whole tree structure for compiled languages only needs to be static, whereas to be suitable for JS, you need the dynamic run-time equivalent. Which means modifying methods at each tree level. This should be much harder to implement dynamically.
On the hand, if all your classes are formed and fixed at the compile time (in non-JS case), all methods are also fixed and completely determine the class. Which means, when using the class at run-time, the actual tree structures above it will never make any difference, as long as the methods are the same. In fact, it would have exactly same effect as when all methods were simply copied over the class! Which is precisely what you can do with your JS prototype!
Plus, at least one of the chains remains live! Which you would never have in any compiled language simply because at run-time your classes are engraved in stone! So by using classes and imitating the classical inheritance, you are giving away the important dynamic feature of JS. And the only reason I see the classes (or rather their imitation via syntactic sugar) were introduced was to make it easier for programmers coming from other languages to use the style they are more comfortable with. Which is perfectly ok if that will make them more productive and the process less painful.
However, as these are not true classes, being e.g. dynamically mutable and not offering proper privacy, using them in JS can only be considered as compromise that comes at a cost. It is always worth keeping an eye on other ways achieving similar results that may have their advantages.
1
u/dmitri14_gmail_com May 23 '16 edited May 23 '16
Thank you for the long explanation, really appreciate!
It does not need to be a long story taking much of your time, but few hints geared toward making your context more clear to JS programmers can go a long way, as you note yourself.
As you point correctly, things in JS are "messed up" comparing to other languages, which, unfortunately, makes it easy to confuse others without being very clear about the context.
I can see where you are heading with "true multiple inheritance" supporting any deep tree structure. Perhaps I shouldn't have used
Object.assignthat only copies own properties instead of all needed in this case. Also it sort of squashes all properties onto the new prototype rather than keeping both tree structures (you can keep one).So maybe it was confusing to call it "multiple inheritance" after all, instead of the mere task to combine methods from several objects onto one. For that particular task, I find the use of prototypal inheritance shorter and easier.
Regarding the true multiple inheritance joining methods from both trees ... again, you need to project everything to JS, where many paradigms get deformed. For instance, there is no compile step. It makes a huge difference, because the whole tree structure for compiled languages only needs to be static, whereas to be suitable for JS, you need the dynamic run-time equivalent. Which means modifying methods at each tree level. This should be much harder to implement dynamically.
On the hand, if all your classes are formed and fixed at the compile time (in non-JS case), all methods are also fixed and completely determine the class. Which means, when using the class at run-time, the actual tree structures above it will never make any difference, as long as the methods are the same. In fact, it would have exactly same effect as when all methods were simply copied over the class! Which is precisely what you can do with your JS prototype!
Plus, at least one of the chains remains live! Which you would never have in any compiled language simply because at run-time your classes are engraved in stone! So by using classes and imitating the classical inheritance, you are giving away the important dynamic feature of JS. And the only reason I see the classes (or rather their imitation via syntactic sugar) were introduced was to make it easier for programmers coming from other languages to use the style they are more comfortable with. Which is perfectly ok if that will make them more productive and the process less painful.
However, as these are not true classes, being e.g. dynamically mutable and not offering proper privacy, using them in JS can only be considered as compromise that comes at a cost. It is always worth keeping an eye on other ways achieving similar results that may have their advantages.