- From: Don Park <donpark@quake.net>
- Date: Fri, 1 May 1998 22:24:03 -0700
- To: <www-dom@w3.org>
David, >> I think there is a clear problem in trying to target DOM at both general >> programming languages as well as scripting languages. ECMAScript offers a >> lot of handy member access constructs which are not available in languages >> like Java. My position is that DOM for scripting languages should be >> separate from DOM for general programming languages. > >I'm not sure I'd go that far, but then I'm not an ECMAScript hacker. What >sorts of things make you say that? Two things: 1. ECMAScript might look similar to Java but is actually very different especially in the member access and error handling. ECMAScript is also used differently than Java. 2. ECMAScript also suffers from the constraints of compatibility with existing DOM implementations in the browsers. DOM API for scripting languages could be made a lot simpler to use and remain compatible with current browsers. For scripting languages also has less constraint as far as 'live' DOM goes. Only requirement I see is that the API be able to handle asynchronous download of XML. This is a lot easier to handle than the general 'anything goes' requirement. DOM API for general languages can be made more sophisticated without having to be constrained by browser DOM implementations. For example, rather than forcing iterators to deal with volatile data structure, synchronization locks can be used with Nodes. >The NodeIterator problems I'm aware of don't relate either to efficiency or >to Java ... they seem to be more conceptual problems. True but, with C++, I can make the problem go away (at least kick it into submission)through brute force. I can't handle the problems in Java unless I do some deep Java Voodoo magic (i.e. bytecode modification during runtime). Regards, Don Park http://www.docuverse.com/personal/index.html
Received on Saturday, 2 May 1998 01:32:11 UTC