Re: [Design] New proposal for DOM TS ML

----- Original Message -----
From: "Curt Arnold" <carnold@houston.rr.com>
To: <www-dom-ts@w3.org>
Sent: Saturday, May 26, 2001 10:57 AM
Subject: 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.
>

[mb] That's exactly my point.  I want to do things like Element.nodeType,
and
Comment.data.

> [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] I don't know what you mean -- maybe the <assign/> statement in your
schema def?  Please expand on the problem with an example.

> [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.
>

[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.

Received on Saturday, 26 May 2001 15:36:18 UTC