[Edbrowse-dev] predefined classes

[Edbrowse-dev] predefined classes

[Karl Dahlke]

[-- 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

Re: [Edbrowse-dev] predefined classes

[Chris Brannon]

Karl Dahlke <eklhad@comcast.net> writes:

> It's also about 4 times as much code.
> So I remain in the "implement it in js" camp,

Let me strengthen your case just a little bit.  Every couple years, we
get forced to make some sweeping changes to the edbrowse JS code, on
account of API deprecation.  Here's a little summary of history since
adopting Spidermonkey.  You started with Spidermonkey JS 1.5.  That was
around for a while, but it was dropped circa 2011.  We had to port to
1.8.5, the new hotness.  In early 2014, 1.8.5 was on the chopping block,
and we had to port to version 24.  Now, version 24 is on the way out.
We have to make more changes.  This is all a bunch of churn.  Nobody
seems too thrilled.  What is going to happen two to three years from now?
I'm tentatively in your camp.  Problem is, I see both sides of this
argument, so I can't make a clear stand either way.

-- Chris

[Edbrowse-dev] predefined classes

[Karl Dahlke]

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

I still like the idea of doing as much as we can in startwindow.js, but when I tried to move a few more things in that direction I ran into trouble.
The TextNode class, that's an easy one right?


TextNode = function() {
this.data = "";
if(arguments.length > 0) {
// do your best to turn the arg into a string.
this.data += arguments[0];
}
}

We won't talk about the 40 lines of mozilla specific C needed to do the same thing in jseng-moz.cpp.  Yuck!
But ... there's a catch.
I can no longer instantiate a TextNode object using the C API.
Sure I can invoke new TextNode in js all I want, it works just fine,
but if it's not a C defined class I can't use the C primitives to spin off objects therefrom.
"So what" you might ask, and you're almost right.
But there is one path of code that needs to do this.
innerHTML = "html string"
parses and renders the html code from within the js process, and objects are created using the native methods, and that includes a TextNode object for each fragment of text on the page.
"So just make a native method to create that particular object, or better still, a native function call you can use to invoke document.createTextNode(), which is how you should be making all your text nodes all the time anyways for consistency."
Right, but I was trying to cut down on the code in jseng-moz.cpp, not make it bigger.
Well it still might be the right path, since I could then move more classes into startwindow.js and use this new native function to call createElement, which is how we should be creating all our nodes anyways for consistency.
So it may still be the right thing to do but I got discouraged / busy with other things and stopped working on it.
I'll wait to see if you have any thoughts.

Meantime I think we should / must go forward with the duktape conversion, whoever has the time and energy for that one.
I'd like to step up, but I am spending all my waking thoughts, and perhaps my last dollar, even dollars I don't have (on credit cards etc) trying to keep my son out of jail for a crime he didn't commit.
For those of you across the pond who don't know, innocent people go to jail all the time in the U.S., and we're ok with that, in fact we love the idea, if the last election is any indicator.
But I digress.
If anyone can help with the duk conversion I'll try to coordinate with my thoughts on moving code from C to js, whence it need not be "converted" any more,
if we can work around some wrinkles, but I don't think that should stop or postpone the conversion, because the clock is ticking.

Thanks for listening.

Karl Dahlke