3 ms·

Two follow-up questions for you, Bob: Do you think it would be wise to implement inner() (perhaps alongside the existing super()) for Dart? If so, would there

Two follow-up questions for you, Bob: Do you think it would be wise to implement inner() (perhaps alongside the existing super()) for Dart? If so, would there be a decent way to do the implementation for the compile-to-JS version, given that there's no native JavaScript way refer to things down the prototype chain instead of up?

jerf 14y ago
"given that there's no native JavaScript way refer to things down the prototype chain instead of up?" For a method "xyz", look for whether there's currently an "xyz_inner" and call that if so. It's easy enough for the Dart compiler to do the resulting paperwork; it's what compilers do. (Yes, it is yet more complicated a bit to keep going down to a second layer of inheritance but it seems like it could be done, just more paperwork. And of course the symbol names are arbitrary, it need not be "inner".)
munificent 14y ago
Do you think it would be wise to implement inner() (perhaps alongside the existing super()) for Dart? I think it would be neat, but it's very unlikely to happen. I'm not one of the language designers. Lars and Kasper are and they've both implemented BETA VMs, so they're certainly aware of inner() and decided not to go in that direction. If so, would there be a decent way to do the implementation for the compile-to-JS version, given that there's no native JavaScript way refer to things down the prototype chain instead of up? If you can statically tell your inheritance chains (i.e. at compile time you know what your superclass is), it should be pretty straightforward, I think. class A { foo() { before(); inner(); after(); } } You'd compile the above to something like: function A() {} A.prototype.foo = function() { before(); this.$A_foo_inner(); after(); } A.prototype.$A_foo_inner = function() {} And a subclass like: class B extends A { foo() { console.log('In B!'); inner(); } } Gets compiled like: function B() {} B.prototype.$A_foo_inner = function() { console.log('In B!'); this.$B_foo_inner(); } B.prototype.$B_foo_inner = function() {} I think something like that would work, but I haven't put much thought into it. The critical bit is being able to tell at compile time that the foo() in B is an override so that you know to compile it to $A_foo_inner and not just foo().

jerf 14y ago

"given that there's no native JavaScript way refer to things down the prototype chain instead of up?" For a method "xyz", look for whether there's currently an "xyz_inner" and call that if so. It's easy enough for the Dart compiler to do the resulting paperwork; it's what compilers do. (Yes, it is yet more complicated a bit to keep going down to a second layer of inheritance but it seems like it could be done, just more paperwork. And of course the symbol names are arbitrary, it need not be "inner".)

munificent 14y ago

Do you think it would be wise to implement inner() (perhaps alongside the existing super()) for Dart? I think it would be neat, but it's very unlikely to happen. I'm not one of the language designers. Lars and Kasper are and they've both implemented BETA VMs, so they're certainly aware of inner() and decided not to go in that direction. If so, would there be a decent way to do the implementation for the compile-to-JS version, given that there's no native JavaScript way refer to things down the prototype chain instead of up? If you can statically tell your inheritance chains (i.e. at compile time you know what your superclass is), it should be pretty straightforward, I think. class A { foo() { before(); inner(); after(); } } You'd compile the above to something like: function A() {} A.prototype.foo = function() { before(); this.$A_foo_inner(); after(); } A.prototype.$A_foo_inner = function() {} And a subclass like: class B extends A { foo() { console.log('In B!'); inner(); } } Gets compiled like: function B() {} B.prototype.$A_foo_inner = function() { console.log('In B!'); this.$B_foo_inner(); } B.prototype.$B_foo_inner = function() {} I think something like that would work, but I haven't put much thought into it. The critical bit is being able to tell at compile time that the foo() in B is an override so that you know to compile it to $A_foo_inner and not just foo().