- From: Arnold, Curt <Curt.Arnold@hyprotech.com>
- Date: Sat, 26 May 2001 19:52:10 -0600
- To: "'www-dom-ts@w3.org'" <www-dom-ts@w3.org>
-----Original Message----- From: Arnold, Curt To: 'Mary Brady ' Sent: 5/26/01 8:51 PM Subject: RE: [Design] New proposal for DOM TS ML [mb] That's exactly my point. I want to do things like Element.nodeType, and Comment.data. [ca] I think these are better done as two operations, an <assertInstanceOf type="Element"/> and the invocation of the Node.nodeType property. Since ECMAScript in particular is not strongly-typed, I think it is best that type assertion tests be explicit. The production of <assertInstanceOf obj="node" type="Comment"/> could be assertTrue(node.nodeType == 8) or maybe an invocation of a harmless method that only exists on the desired interface on ECMAScript. [mb] I don't know what you mean -- maybe the <assign/> statement in your schema def? Please expand on the problem with an example. [ca] In my schema def, I had an element for assignment of the value of a literal or a variable to another variable and had also used a "var" attribute for the left hand side: <assign var="x" value="8"/> <assign var="x" value="y"/> Also, simple math: <substract var="x" op1="1" op2="2"/> Using "returnVar" for these would be inappropriate and there is an appeal to have the same attribute name, hence I would stick with "var" for the return value of functions. [mb] Yes, you do need to track the type, and in the original example, all variables were generated of the type var_Node, var_Element, etc -- tracking was not so difficult -- if clarity is the issue, we can make the obj required. [ca] I'd prefer it to be required.
Received on Saturday, 26 May 2001 21:53:02 UTC