Re: [Design] New proposal for DOM TS ML

>[mb] It's not a matter of do I like the name or not -- Dimitris had
indicated that
>he would like to see as much reuse as possible, and I agree.  I have raised
the
>inheritance issue several times -- the current proposal allows for this --
>quite honestly, I don't like having to specify  <Node><method ...></Node>
>either, but I do like the reuse that this approach affords us.

[ca] I'm all for reuse, but I like minimization better.  I tried to respond
to your inheritance issues
in a couple of messages.  The only piece of information that I see that is
necessary
to have for code generation is the interface in which a method or property
was
introduced.  If you needed to distinguish between Comment.data and
CharacterData.data
to generate the code then the nested elements would be a good approach,
but I forsee no need to do that (apart from the cast check which could be
done
as a distinct assertion).  I never had any intentions of adding, for
example,
<Element.nodeType/>, for example.

[ca] I actually was getting tired of using Node.getNodeName too.  Since with
the exception
of the getElementByTagNames and code's, all property and method names are
unique, the defining interface is unambiguous and doesn't need to be
expressed
in the test document.

[mb] I have no preference -- I wasn't looking directly at your schema when I
started typing.  Maybe it should be returnVar -- so that it is not confused
with
your next point.

[ca]I like having the consistancy with <assign/> where returnVar would no
feel right since there
is nothing being called.

[mb]  No, this was just an oversight.  Thanks for pointing it out.
Initially, we tried to get away without this -- since most of the methods
actually
operate on the returnVar of the previous invocation, the transformation
could do this for us.  Unfortunately, there are a few cases where you are
not operating on the returnVar of the previous invocation -- so I agree, it
is much cleaner to put it in -- does everybody like obj, or should it be
something else.  Maybe we could have the best of both, and put it in as
optional -- if it is there, use it; otherwise use the returnVar of the
previous invocation.

[ca]I don't like the complexity that "temporary variables" would add to the
code
generator or to the generated code.  You'd also have to be able to imply the
type of the temporary variable from the context and generate names for
the temporary variable.

Received on Saturday, 26 May 2001 10:55:02 UTC