<luke.leighton@gmail.com>:
>
> language bindings involve the following:
>
> 1) mapping one-for-one with each and every single function (DOM in
> this case: 2,000+ of them)
> 2) mapping one-for-one with each and every single property (DOM:
> 20,000 properties yes really twenty THOUSAND)
I think it doesn't matter to distinguish between functions and
properties,
I mean, properties must be implementat as functions, anyway. Because
you will
need to trigger events when properties change.
> 3) converting between the argument types on the function calls from
> one language to the other
> 4) converting the _return_ result of the function into the target
> language
> 5) taking care of ref-counts on objects so that when an object goes
> out of scope in the language-bindings its corresponding object gets
> de-ref'd too
> 6) taking care of returning the *same* object if it has already been
> referenced once before (so that == works in the target language).
>
> you _can_ choose to ignore the experience and knowledge of those
> people, but i can pretty much predict with 99% accuracy that should
> you choose to have ignored that experience and knowledge, you will
> soon wish that you hadn't :)
I'm not ignoring that, for sure.
> no i'm not. i'd love to hear of alternatives. however... having
> dealt with all the major browser engines and a couple of the obscure
> ones as well, i've been around the block shall we say, and they
> genuinely fall into just those two categories [a COM of some
> description or a massive half-way-house auto-generator]
>
> but think: how the heck is the "single dispatcher function" supposed
> to *know* about the layout of those vtables? how does it "know" that
> the first pointer is to.. ok lemme grab an example...
>
> /* DOM Attr vtable */
> typedef struct dom_attr_vtable {
> struct dom_node_vtable base;
>
> dom_exception (*dom_attr_get_name)(struct dom_attr *attr,
> dom_string **result);
> dom_exception (*dom_attr_get_specified)(struct dom_attr *attr,
> bool *result);
>
> right.
>
> how is the proposed "single dispatcher function" supposed to "know"
> that the first pointer is to dom_attr_get_name ?
I'm not familar with libdom, so probably my thoughts are totally
missuse libdom ;)
Ok, this may sound childish to you but I thought about an dispatcher,
not
an function pointer assignment.
something like:
switch( int which_dom_member_shall_be_called ) {
case dom_attr_width:
_dom_html_document_get_title( varargs );
break;
20000 different dom function calls ...
}
Of course, that dispatch table would be generated dynamically.
One could also think about something like:
dom_attr_getter_and_setters [
...
]
dom_att_getter_or_setter_function_pointer =
&dom_attr_getter_and_setters[attribute_type];
(dom_att_getter_or_setter_function_pointer)( varargs );
> how is it supposed to "know" that the first argument is a struct
> dom_attr and the second argument is a dom_string?
IDL file, or something like that.
> i'm aware of that. GObject-introspection, COM and XPCOM all deal
> with c. it's a little awkward: you have to follow some very specific
> design rules related to refcounting, but you've implemented
> refcounting in libdom so i know you're intimately familiar with that.
No, I know almost nothing about it.
>
> yes. again - it's not that easy: dynamic languages have
> refcounting,
> garbage collection etc. the refcounting basically has to map
> one-to-one with the DOM object being "represented".
I'm pretty sure JavaScript itself doesn't do ANY DOM object ref
counting...
> GObject-In
>>> b.iii) GObject with Introspection. this one is interesting,
>>> because
>>> it turns out that gobject-introspection now has *multiple* language
>>> support... including *two* separate javascript bindings! in other
>>> words if you were to adopt gobject as the netsurf middleware,
>>> should
>>> you choose this route, you'd *automatically* get javascript
>>> bindings... *for free*... as well as several other programming
>>> languages.
No... Is it really that way?? AFAIK Gjs and seed are bindings to GTK.
Call GTK from JS - that's it. That's of no use for a DOM
implementation. Is it?
> for example: if you chose GObject-Introspection, you would *only*
> need to implement a libdom-to-gobject system, and then you would
> *automatically* gain those two javascript languages that are being
> developed by the gnome team: the addition of others would be a small
> task probably about 3,000 lines of code or so.
That sounds indeed "fitting", however, I can't see how introspection is
involved here.
To me it sounds like it also can be done with old GObject. It should be
available to
all platforms using NetSurf.
> if you don't use some sort of middleware you will have to do this
> *manually*. and how many different event types are there? there's
> over 50, aren't there. that's a hell of a lot of manual coding when
> middleware will get you that code *for free*.
Of course, I was always referring to some kind of code auto-generator ,
but I doubt the generator will generate window.alert() for 7 different
GUI systems
without manual coding ;)
Greets,
m
No comments:
Post a Comment