A Google friend with Polish-American accent pronounces "the DOM" as "the Dumb", and I agree. Don't fret about usability of future DOM APIs in an evolution of SoundScript. I'm 100% sure they can be as sweet as Dart's Dumb, er, DOM. :-)
Isn't this problem inherent in the Soundscript type system, rather than a problem of the DOM? For example:
class Node { ... }
class FancyNode extends Node { ... }
function createNode() : Node => new FancyNode();
function doStuff(Node n) { ... }
doStuff(createNode()); // Static error - developer scratches his head - how do I fix this
doStuff(<FancyNode>createNode()); // There I fixed it. But at what cost to productivity.
Or perhaps (Not sure how Any<T> works - just guessing):
function doStuff2(Any<Node> n) { ... } // Developer - hey what's this Any<T> thing? More head scratching.
Is the extra complexity worth it, what benefits does it bring, and what are the productivity costs? Will soundness actually help runtime performance (Not proven). Will it make security harder? i.e. performance optimisations that rely on the sound type system mean that type spoofing can lead to vulnerabilities.
I keep on rambling - sorry - I find this stuff fascinating. Fun job you've got ;)
There's no type error in what you wrote, with or without the cast. But we're way over-indented now. Suggest trying ed-discuss for direct convo with Andreas R.
1) Large interdependent libraries that try to "fix" the DOM (and provide widgets, MVW, etc.
2) The common practice of loading scripts over external domains. This compromises privacy & security and is possible because of the same-origin policy.
The DOM is not idiot-proof. But the way that they are using it causes undue problems.
/be