[Edbrowse-dev] predefined classes

[Karl Dahlke <eklhad@comcast.net>]

[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]

When considering the switch from mozilla to duktape, much of jseng-moz.cpp is the definition of DOM classes with various methods.
These definitions are of course entirely mozilla specific.
They are written using mozilla structs and so on.
This becomes a big chunk of work when switching to duktape.
When I wrote these, I didn't understand that some classes can be defined in pure js, in startwindow.js.
If I had known how to do that, then many class definitions would be there, and not in jseng-moz.cpp.
They would not have to be converted to duktape.
In other words, less work for us now.
Sure there are native methods in these classes, but some of those methods can be defined as simple static methods then linked into the class under the appropriate function name.
This is how we built the class XMLHttpRequest.
So before we switch to duktape, whoever is going to take that on,
I suggest we morph the other classes into pure js in startwindow.js, calling native methods where need be, following the model of XMLHttpRequest.
They won't be defined in C, and we won't have to rewrite all that code whenever we switch engines.
I would start with the URL class, which I've thought for a long time could be pure js, I don't even think it needs any native methods.
Then another class and another and so on.
What do you think?

I might anticipate some disagreement on this matter, and that's ok, some have advocated exactly the opposite,
moving stuff out of startwindow.js and back into C,
but the more of that you do, the harder it is to make these conversions from one engine to another.
It's also about 4 times as much code.
So I remain in the "implement it in js" camp,
and would suggest we do more of that, as much as we can, then convert from mozilla to duktape.

Karl Dahlke