IDL for SAX2

[Lars Marius Garshol]

* Lars Marius Garshol
|
| Many things in SAX won't wash in IDL, such as the use of the
| Java-specific InputStream, Reader and Locale objects.

* uche ogbuji
| 
| IDL does not concern itself with the implementation of any object:
| strictly interface, as its name promises.  You can use InputStream,
| Reader, etc. etc. to your heart's content.  In fact, you can even
| improve on the current Java approach by actually _defining_ the
| interface for those classes, saving non-Java users a spurious trip
| through the Javadoc.

Maybe, but you don't want these to be InputStream, Reader and Locale
in Python, C++ or Common Lisp. You want them to be Pyton file objects,
C++ streams and Common Lisp streams. So although it may work for Java
it won't work as well everywhere else.
 
* Lars Marius Garshol
|
| Also, IDL has a problem in that it's sort of a least common
| denominator, and thus leaves out many useful language-specific
| things.
 
* uche ogbuji
|
| Examples, please. 

Python 'magic' methods such as __getitem__, Common Lisp generic
methods, Eiffel/Sather invariants and post-/preconditions, Sather
iterators, Python/Common Lisp keyword arguments, Java/C++ overloading
and so on.

This is a problem that isn't really avoidable when you want to
seamlessly cross language boundaries, but it's not clear to me that
that is what we want to do in this particular case.

| I don't think your above example of Java-specific objects really
| minimizes the usefulness of IDL.

Not in general, but I think the fact that you want to map those
objects to different kinds of objects in different languages does mean
that IDL can't be used directly anyway, and then you may as well do
the whole translation manually.

To take one example we've now introduced AttributeList2, a subclass of
AttributeList, which is passed to the usual startElement method. In
Java you need to cast this object to get at the new methods, which is
awkward, means a run-time type-check and sort of defeats the point of
having typing in the first place.

In Common Lisp you'd rather have

(defmethod start-element((dh my-document-handler) (name string)
                         (al attribute-list))
  (error "Dang, we need a SAX 2.0 parser!"))

(defmethod start-element((dh my-document-handler) (name string)
                         (al attribute-list2))
  ; safely use attribute-list2 with no casting, no performance penalty
  ; and no typing problems
  )

This IDL can't do for you, because IDL doesn't have the concept of
generic methods.
 
* Lars Marius Garshol
|
| If there ever is a published SAX spec I think it should use IDL to be
| politically correct and point out potential language-mapping problems.
| However, the actual utility of IDL I think is low in this particular
| case.
 
* uche ogbuji
|
| It's not a matter of "politically correct".  IDL is an excellent
| _engineering_ tool whenever you need to define interface.  I have
| used it time and time in my career, and I find that the ability to
| generate stubs in any native language directly from the IDL, thus
| ensuring adherence to the interface, saves much development time.

When you want to talk to implementations in other processes, on other
computers and in other languages, yes. But I don't think that's really
what we want in this case, to the cost of having less natural
translations to the various languages.

--Lars M.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)