W3C home > Mailing lists > Public > www-dom@w3.org > July to September 1998

Re: parentNode

From: Stephen R. Savitzky <steve@crc.ricoh.com>
Date: 28 Jul 1998 16:01:17 -0700
To: keshlam@us.ibm.com
Cc: www-dom@w3.org
Message-ID: <qck94x8ts2.fsf@gelion.crc.ricoh.com>
keshlam@us.ibm.com writes:

>      There are other ways of creating nodes, however: most languages have a
>      "new" operator.
> It's legitimate to say "That will allocate the space but will not produce a
> properly initialized/valid/usable object."

In Java and Smalltalk (and, indeed, every OO language I know of except
badly-written C++) "new" produces a properly initialized, valid, useable

> Remember, the DOM _is_ an OO design; objects may be produced only by valid
> constructors and factories -- and a given object's public API may have
> _only_ factories and not constructors.

Actually, the DOM is a _subset_ of an OO design -- it's a set of
standardized interfaces to a set of classes that, under the hood, can have
other interfaces (even public ones) as well.  Our application simply cannot
be written using only the DOM interfaces as specified; with several tens of
additional classes it could be written but would have at most half the
performance that it would with extended interfaces and more appropriate
behavior.  It is NOT likely to be rewritten in JavaScript.

> But if that's the desired behavior, the spec should make it unmistakable.

I don't believe that the spec _should_ include this restriction.  In any
case, the DOM specifies only interfaces; in most languages one can go
``behind the DOM's back'' and go direct to the implementation classes.
Besides, as far as I know one can't specify a constructor in an IDL

 Stephen R. Savitzky   Chief Software Scientist, Ricoh Silicon Valley, Inc., 
<steve@rsv.ricoh.com>                            California Research Center
 voice: 650.496.5710   fax: 650.854.8740    URL: http://rsv.ricoh.com/~steve/
  home: <steve@starport.com> URL: http://www.starport.com/people/steve/
Received on Tuesday, 28 July 1998 18:56:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:04 UTC