Re: Defs format and XML
- From: Mike Kestner <mkestner speakeasy net>
- To: James Henstridge <james daa com au>
- Cc: language-bindings gnome org
- Subject: Re: Defs format and XML
- Date: 14 Jan 2002 03:59:22 -0600
On Mon, 2002-01-14 at 00:03, James Henstridge wrote:
> You say that an XML format was easier to use. This is likely to be true
> for any language where XML parsers are readily available (or come
> standard), but s-expression parsers are not. This probably covers
> almost every language available today (except scheme/lisp which have
> s-expression parsers built in :).
Yes, exactly. I found myself writing my C# code generator in perl
because it seemed the best way to parse s-expressions. By contrast, my
XML format is parsed for free using the standard C# class libraries.
> It would be fairly easy to map the existing defs format to XML, and the
> changes in my python code generator would be fairly localised (I already
> went through the process once in the going from Havoc's version 2 format
> to the current one). I can't speak for other developers though (Ariel?,
> Murray?).
My XML format is not just a remap of s-expressions to XML. I can try to
define a DTD and post it for discussion if anyone's interested. In a
nutshell, it's a hierarchical format, organized with an <api> root
element, which contains <namespace> elements. The types are children of
<namespace>. <object> elements contain all the <field>, <property>,
<signal>, and <method> child elements pertaining to the type. This seems
an optimal situation for any object-oriented language binding that
contains a standard DOM parser.
> You also said that the current defs format was missing some features
> needed for the GTK# binding. Was there any particular features you are
> looking for? If the problems can be identified, then hopefully we can
> integrate the ideas into the defs spec.
The latest spec is not missing much. My statement was more related to
the available defs files, not the defs format. I found myself writing
perl scripts to generate s-expr based defs for Callbacks/Function
pointer types, structures, signals, properties, etc... I even found some
enums missing from the files, although I'm sure that was just because
the files hadn't been regenerated in a while. I figured that since I
was writing all these source parsing scripts, I might as well have them
produce a format that was easier for me to use in a C# based code
generator. A hierarchical XML doc seemed the obvious choice.
You once asked me why I needed all the struct definitions. One challenge
that may be unique for me with Gtk# is that I don't have access to the C
headers at compile time. I suspect that most of the existing bindings
have some sort of compiled glue level access to the C headers, which
allows them to ignore things like structure types.
In order for me to invoke a function, I need to declare a signature for
it and identify the dll that contains it. For each parameter in the
signature, I have to either map it to an existing C# type and provide
marshaling code to the native type, or I have to define a new C# type
with marshaling attributes to utilize the built-in PInvoke marshaling
capabilities.
> Please don't misinterpret this as a stake burning :) I would just like
> to see all LBs using the same formats/code where appropriate.
I agree that a common format is preferable. Before going into stealth
mode and reinventing this wheel, I invested considerable time in trying
to make the s-expr defs format work for Gtk#. It was my intention to
come back and preach about XML's virtues after fully debugging the XML
format and source parser. I'm currently parsing up through gtk+, and
it's looking pretty good now. I haven't exercised all the elements with
my generator, though. Hopefully I'll have all the kinks worked out by
end of Jan.
Anyway, thanks for the note, and let me know if I can clarify any of the
above.
Mike
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]