I've given thought to how Javascript implements inheritance. Natively we have prototypal inheritance. However, a lot of frameworks make use of inheritance by extension. Backbone.js does. Underscore.js and jQuery both offers "extend" methods. Essentially, what they're supporting are mixins. The trouble is that the mixins are static. At the moment you mixin a module, the modified object/prototype is what it is. You can modify the original mixin object, but that won't impact any of the objects/prototypes having already integrated the mixin.
Now I'm thinking about this and perhaps this is a stretch, but couldn't this be solved by making an adjustment to how javascript supports prototypal inheritance? What if instead of constructors supporting a single "prototype" property, they supported a "prototypes" property (an array)? I mean when you think of the nuts and bolts behind inheritance it's nothing but a deterministic means of resolving a method invocation. You call a method on an object and the interpreter uses an algorithm to locate the method, starting on the object itself and drilling down the prototype chain. If instead, the prototype chain involved an array of prototypes, we'd still have a deterministic means of locating the desired method. We'd also have a better form of multiple inheritance.
Additionally, mixins could be pushed onto the prototypes array. (You could even insert a mixin just above some other mixin if you wanted.) It wouldn't be necessary to copy methods. Modifications to the original mixin would actually take effect across the board. This alone is a good thing, but there's even more good news, at least when it comes to the apps I've worked on.
I find that my entities have a need for dynamic typing. For example a Person could also be a Father or an Employee. DCI is gaining traction. Using DCI you make your classes simple and inject role-specific functionality into objects just as the functionality is needed. This is all good and I like the approach for the most part. What I don't like is that in a long-lived user session I have the need not only to mixin role-specific functionality, but to unmix it. When I say "long-lived" think in terms of a single-page web apps where you may be managing state for quite some time--up until the point that the user leaves the app. One thing I don't like in a language (including Javascript and Ruby) is that although it's easy to extend objects, unextending is not easy. Developers have attempted to solve this in Ruby by writing libraries (like Mixology), but I'm not happy that a custom library is necessary for something that I feel the language should support natively. If you had a prototypes array, as I'm suggesting, you simply drop the mixin reference and you're done. It's a simple mental model and no fancy library is necessary.
Couldn't this be written in a backwards compatible way? Just because we have a prototypes property doesn't mean that we couldn't also have a virtual prototype property that gets/sets the first item in the array.
I was considering making an official proposal about this to ECMAScript, but I thought I should put this in front of the Javascript community to see what holes might be in my proposal. Does this sound workable? Do any disadvantages outweigh the advantages?
Now I'm thinking about this and perhaps this is a stretch, but couldn't this be solved by making an adjustment to how javascript supports prototypal inheritance? What if instead of constructors supporting a single "prototype" property, they supported a "prototypes" property (an array)? I mean when you think of the nuts and bolts behind inheritance it's nothing but a deterministic means of resolving a method invocation. You call a method on an object and the interpreter uses an algorithm to locate the method, starting on the object itself and drilling down the prototype chain. If instead, the prototype chain involved an array of prototypes, we'd still have a deterministic means of locating the desired method. We'd also have a better form of multiple inheritance.
Additionally, mixins could be pushed onto the prototypes array. (You could even insert a mixin just above some other mixin if you wanted.) It wouldn't be necessary to copy methods. Modifications to the original mixin would actually take effect across the board. This alone is a good thing, but there's even more good news, at least when it comes to the apps I've worked on.
I find that my entities have a need for dynamic typing. For example a Person could also be a Father or an Employee. DCI is gaining traction. Using DCI you make your classes simple and inject role-specific functionality into objects just as the functionality is needed. This is all good and I like the approach for the most part. What I don't like is that in a long-lived user session I have the need not only to mixin role-specific functionality, but to unmix it. When I say "long-lived" think in terms of a single-page web apps where you may be managing state for quite some time--up until the point that the user leaves the app. One thing I don't like in a language (including Javascript and Ruby) is that although it's easy to extend objects, unextending is not easy. Developers have attempted to solve this in Ruby by writing libraries (like Mixology), but I'm not happy that a custom library is necessary for something that I feel the language should support natively. If you had a prototypes array, as I'm suggesting, you simply drop the mixin reference and you're done. It's a simple mental model and no fancy library is necessary.
Couldn't this be written in a backwards compatible way? Just because we have a prototypes property doesn't mean that we couldn't also have a virtual prototype property that gets/sets the first item in the array.
I was considering making an official proposal about this to ECMAScript, but I thought I should put this in front of the Javascript community to see what holes might be in my proposal. Does this sound workable? Do any disadvantages outweigh the advantages?