Re: The "splice" call

Jeff Mackay wrote:

> Programming errors should be caught with explicit exceptions, and
> programmers should be forced to deal with those errors--that's one of
> the
> principles behind the "design by contract" ideas behind specifying the
>
> exceptions thrown by a method.  The interface is a contract between
> the
> implementor and the client--and exceptions are consequences of clients
> not
> upholding their side of the agreement.

I suspect you are right.  I just see the proliferation of "catch
(Throwable t) {}" and know I would much rather have a runtime exception
that at least goes somewhere, which in a sense preserves the contract at
least by preventing further execution.

> Speaking of which.... It may actually be a good idea to specify a
> "ValidationException" that may be thrown by Node.insertBefore and
> AttributeList.setAttribute, (and maybe for other methods that modify
> the
> DOM) if only as a placeholder for the Level 2 (or 3 or 4) work.

I sincerely hope that validation is kept as an independant process.  I
would hope to keep validation as a seperate operation from the
manipulation of the DOM, with sets of higher-level service routines
which can incorporate validation as required.

> I think
> this was mentioned before, but I think it was "deferred".  Without the
>
> exception defined, an implementor wanting to perform immediate
> validation
> (e.g. for documents constructed outside of a parser) MUST resort to
> runtime
> exceptions. If the ValidationException is defined, implementations can
> (but
> are not required to) perform immediate validation.

I disagree.  I have created a DOM before which did this type of
validation as it was modified on-the-fly.  I believe it is not worth the
great effort at the core level, because there are so many other aspects
and a variety of concepts and models to being valid, and
auto-correcting, even directing the manipulations according to what is
valid.

Also, at this low core level, the model may have to go through multiple
invalid states before the high-level can bring it back into a valid
state, or you are forced to produce a core which, as an atomic
operation, can do every possible manipulation between valid states, even
if, for example, you have an optional subgroup of elements which must be
added or removed as a set before the model is valid again.

> I'd advise caution here. Advanced operations can be provided by
> implementations that add value to the standard specification. And I
> think
> splice is one of those operations. While it is certainly necessary for
> a
> certain class of applications, others won't require it at all. I'd
> prefer
> that it be removed from the interface. The more complicated the
> interfaces,
> the more difficult they are to implement (take the recent discussion
> on
> NodeIterators as proof of this argument), and the greater the chances
> for
> differences in implementation to have an adverse affect on
> interoperability.

I agree completely here.  I would group splice together with the
more-advanced set of operations (perhaps together with those I discussed
above which implicitly validate).  The more advanced set could include
the more complete set of splice-like operations, among others.

Ray Whitmer
ray@corel.com

Received on Wednesday, 20 May 1998 12:32:21 UTC