> Ok, this may sound childish to you but I thought about an dispatcher, not
> an function pointer assignment.
childish is good! ok, child-like is better. children are innocent
and don't judge. anyway. on track...
dispatcher. yes.
> 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.
right. right! ok, that's the "webkit-esque" approach. and also the
python-gobject "codegen.py" approach.
but wait... yes you have a switch statement... but where do the
arguments come from? you now have to somehow encode those as well,
yeah? you can either dynamically generate the code for those function
parameters, or perhaps you could just... say "ok function: we're going
to trust the caller" (i.e. you trust the programmer).
so in _some_ of these things (these Common Object Model thingies)
they actually work by pushing the function call parameters onto the
stack *manually* (assembly code level) and then doing an
assembly-level CALL! it works, but if you get it wrong, you're
f****d.
python-ctypes allows you to do this. it's very risky though, and
hellishly difficult to get right for portability, which is why the
python software foundation refuses to allow any module that depends on
ctypes to be added to the standard python distribution.
so, anyway, assuming you don't choose that route, you now have to
auto-generate not just a dispatch table containing 3,000 switch
statement entries but also it has to encode eeevvvvveryyy
siiinnggggllee parameter call, converting from javascript to c.
the end-result is HUNDREDS of thousands of lines of auto-generated
code. which, when you compile it, you just added a whopping 5
*megabyte* hunk of binary to netsurf.
> 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.
you got it :) which are missing from libdom btw (whoops). so, the
netsurf project is going to have to find some of those, from
somewhere. there's three existing sets to choose from: the ones in
webkit, the ones in wine and the ones in firefox. or... you could
roll your own. which will take... a long time.
>
>
>> 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.
ah, ok. err... where's the doc on it...
ok, libdom's "docs/RefCnt" file. basically any object that has been
constructed in memory, you need it to "stick around". but it's been
used by several people, right? so, very simple: you add a "reference
count". any piece of code that wants to use that object, it increases
the reference count by one. when it's done, it decrements the count.
when the count gets to zero, you know that you can destroy the object.
>>
>> 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...
ohhhh yes it does :) ok, the language javascript has to do
refcounting. that's what all the fuss is about in firefox with their
memory leaks on garbage collection and so on.
you can't _not_ do refcounting and garbage collection. it's a
dynamic programming language.
>> 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??
yeeeees :)
> AFAIK Gjs and seed are bindings to GTK.
noooo :)
> Call GTK from JS - that's it.
it's call anything that is "gobject-introspection-enabled". GTK is
just *ONE* library which is gobject-enabled. it confused the heck out
of me, at first. but yes, all GTK objects derive from the base type
"GObject".
so, quite literally, just like in that python-gi example, if you made
libdom gobject-introspection-aware, you would be able IMMEDIATELY to
call ANY function in the DOM, from javascript (gjs or seed)... without
having to write even ONE extra line of c code.
not ONE single line. it's that simple / powerful.
>> 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.
yes... but if you use old gobject, it means you can't use the
"self-describing" part. that means you have to generate hundreds of
thousands of lines of code, which gives you a whopping-sized binary.
if there weren't 20,000 properties and 3,000 functions in the DOM
specification, this wouldn't be a problem.
> 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 ;)
if you use COM, XPCOM, GObject-Introspection or any other type of
Common Object Model, the whole point is: there will BE no further
manual coding required - period.
i can't make it any plainer. beyond repeating this point more and
more times, it becomes a matter of belief. and to overcome that, i
believe it may prove helpful for you to try experimenting with say...
gobject-introspection.
actually try it out. find some tutorials and just... play.
l.
No comments:
Post a Comment