Am Donnerstag, den 08.03.2012, 20:23 +0100 schrieb lkcl luke
<[email protected]>:
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 implementet 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
