[Edbrowse-dev] getters and setters in straight javascript

[Edbrowse-dev] getters and setters in straight javascript

[Karl Dahlke]

Friends, before Adam dives into javascript duktape engine, if he
could procrastinate just a couple more days, I would like to ask a question.
This is just for discussion, I don't know enough even to have an opinion.

The edbrowse-js that we have working today, based on mozilla,
is 2354 lines of c++.
Within this, the setters and getters for the URL class are 439 lines of code,
almost one fifth of the total.
If we include other setter code,
such as document.cookie = "foo=bar" folding this into the entire
document.cookie string,
we could be talking about a quarter of the code or more.
This is all C, and all tightly coupled to the getter syntaax
of whatever engine we are using, all has to be modified
whenever we upgrade or switch engines.
My question is, could some of this be done by generic javascript
in the sourcefile startwindow.js?
Does it really have to be native C?
There are already some URL.prototype definitions in there,
perhaps we could add some getters and setters easily
that would do all the stuff I do in C today.
Have a look at this web page.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Working_with_Objects
Read the section Defining getters and setters

Is this mozilla specific, or generic javascript?
Perhaps run some of the examples through d8.

The examples seem to suggest object.x can be defined as a getter or setter
but not both.
If that is the case then it won't work for us.
URL.port needs to fetch the port, 80 for example,
but url.port = 8080 needs to set the port and also change the port
in url.href.

This is an area of javascript that I didn't know existed
at all until last week, so I'm still learning.
Just raising some questions,
because the several hundred lines of C code that implement the setters
are a bit ugly, or at least awkward and engine specific.

Karl Dahlke

[Edbrowse-dev] getters and setters in straight javascript

[Karl Dahlke]

This is a followup to my previous message.
If getters and setters are feasible in straight javascript,
here is how the url class would look.
If you paste this into startwindow.js it compiles properly.
The syntax is right.
And the code looks right to me, but of course it blows up
because there are then js setters and C setters and they collide.
I would have to remove the C setters from jseng-moz.cpp.
Anyways here it is to give us an idea of how
js setters, for the URL class, would look,
using much less code, independent of the js engine.
Now I need to step back and just think about it for a bit.
don't worry, I haven't pushed anything, I'm just playing.


var $urlpro = URL.prototype;

/* rebuild the href string from its components.
 * Call this when a component changes.
 * All components are strings, except for port,
 * and all should be defined, even if they are empty. */
$urlpro.rebuild = function() {
var h = "";
if(this.protocol$val.length) {
h = this.protocol$val + "://";
}
if(this.host$val.length) {
h += this.host$val;
} else if(this.hostname$val.length) {
h += this.hostname$val;
if(this.port$val != 0)
h += ":" + this.port$val;
}
if(this.pathname$val.length) {
// pathname should always begin with /, should we check for that?
h += this.pathname$val;
}
if(this.search$val.length) {
// search should always begin with ?, should we check for that?
h += this.search$val;
}
if(this.hash$val.length) {
// hash should always begin with #, should we check for that?
h += this.hash$val;
}
this.href$val = h;
};

Object.defineProperty($urlpro, "protocol", {
  get: function() {return this.protocol$val; },
  set: function(v) { this.protocol$val = v; this.rebuild(); }
});

Object.defineProperty($urlpro, "pathname", {
  get: function() {return this.pathname$val; },
  set: function(v) { this.pathname$val = v; this.rebuild(); }
});

Object.defineProperty($urlpro, "search", {
  get: function() {return this.search$val; },
  set: function(v) { this.search$val = v; this.rebuild(); }
});

Object.defineProperty($urlpro, "hash", {
  get: function() {return this.hash$val; },
  set: function(v) { this.hash$val = v; this.rebuild(); }
});

Object.defineProperty($urlpro, "port", {
  get: function() {return this.port$val; },
  set: function(v) { this.port$val = v;
if(this.hostname$val.length)
this.host$val = this.hostname$val + ":" + v;
this.rebuild(); }
});

Object.defineProperty($urlpro, "hostname", {
  get: function() {return this.hostname$val; },
  set: function(v) { this.hostname$val = v;
if(this.port$val)
this.host$val = v + ":" +  this.port$val;
this.rebuild(); }
});

Object.defineProperty($urlpro, "href", {
  get: function() {return this.href$val; },
  set: function(v) { this.href$val = v;
// initialize components to empty,
// then fill them in from href if they are present */
this.protocol$val = "";
this.hostname$val = "";
this.port$val = 0;
this.host$val = "";
this.pathname$val = "";
this.search$val = "";
this.hash$val = "";
if(v.match(/^[a-zA-Z]+:\/\//)) {
this.protocol$val = v.replace(/:\/\/.*/, "");
v = v.replace(/^[a-zA-z]+:\/\//, "");
}
if(v.match(/[/#?]/)) {
/* contains / ? or # */
this.host$val = v.replace(/[/#?].*/, "");
v = v.replace(/^[^/#?]*/, "");
} else {
/* no / ? or #, the whole thing is the host, www.foo.bar */
this.host$val = v;
v = "";
}
if(this.host$val.match(/:/)) {
this.hostname$val = this.host$val.replace(/:.*/, "");
this.port$val = this.host$val.replace(/^.*:/, "");
/* port has to be an integer */
this.port$val = parseInt(this.port$val);
} else {
this.hostname$val = this.host$val;
}
if(v.match(/[#?]/)) {
this.pathname$val = v.replace(/[#?].*/, "");
v = v.replace(/^[^#?]*/, "");
} else {
this.pathmname$val = v;
v = "";
}
if(this.pathname$val == "")
this.pathname$val = "/";
if(v.match(/#/)) {
this.search$val = v.replace(/#.*/, "");
this.hash$val = v.replace(/^[^#]*/, "");
} else {
this.search$val = v;
}
}
});

Re: [Edbrowse-dev] getters and setters in straight javascript

[Chris Brannon]

Karl Dahlke <eklhad@comcast.net> writes:

> My question is, could some of this be done by generic javascript
> in the sourcefile startwindow.js?
> Does it really have to be native C?

There's nothing Mozilla specific about defineProperty.  And yes, a
property can be defined with both a getter and setter.  So it seems that
the answer is yes.

-- Chris

[Edbrowse-dev] getters and setters in straight javascript

[Karl Dahlke]

Ok - URL setters are now in startwindow.js.
I verified that the setter syntax and invokation etc works in d8,
so I believe it is sufficiently generic.
I traded 400 lines of awkward bug-prone confusing engine-specific C
for 100 lines of plain javascript.
That's another 400 lines you won't have to convert when switching to duktape.
jsrt runs, and it contains a lot of url side effects testing.
I don't think I broke anything.

It may also be worth moving the document.cookie setter out of native C
and into js, though a small part of it must remain native to push
the cookie back to edbrowse and curl and the jar.
I'll be looking at that one over the next couple of days.

Karl Dahlke

Re: [Edbrowse-dev] getters and setters in straight javascript

[Adam Thompson]

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

On Sat, Jun 13, 2015 at 06:50:49AM -0400, Karl Dahlke wrote:
> This is a followup to my previous message.
> If getters and setters are feasible in straight javascript,
> here is how the url class would look.
> If you paste this into startwindow.js it compiles properly.
> The syntax is right.
> And the code looks right to me, but of course it blows up
> because there are then js setters and C setters and they collide.

Does this actually work with the existing machinary?
Some of the code in startwindow.js doesn't work as expected in terms of
rendering elements (at least as far as I know),
I'm thinking particularly in terms of the link between appendchild and the rendered html.
Of course, if I'm wrong, please correct me.
In addition, we're actually violating the DOM spec by doing some of these
things in pure js since they have the concept of "host objects"
which are defined by the host and don't quite behave like ordinary js objects
in terms of not having prototypes etc.
I guess my thoughts on this are that,
once we actually settle on a suitable js engine (duktape, mozilla,
whatever) we should re-evaluate what's in startwindow.js and what's in c to ensure that:
a) It actually works rather than just keeping js happy
b) it doesn't rely on engine-specific js
c) it's maintainable

Once we sort the parser and js engine,
we'll probably need to combine the two into one process anyway to make this
whole thing work much better since we're going to have to get a better link
between js-generated DOM and html-generated DOM.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Edbrowse-dev] getters and setters in straight javascript

[Adam Thompson]

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

On Sun, Jun 14, 2015 at 05:11:05AM -0400, Karl Dahlke wrote:
> Ok - URL setters are now in startwindow.js.
> I verified that the setter syntax and invokation etc works in d8,
> so I believe it is sufficiently generic.
> I traded 400 lines of awkward bug-prone confusing engine-specific C
> for 100 lines of plain javascript.
> That's another 400 lines you won't have to convert when switching to duktape.
> jsrt runs, and it contains a lot of url side effects testing.
> I don't think I broke anything.

Ok, sent previous message before receiving this one,
but my point about DOM specs still stands.

> It may also be worth moving the document.cookie setter out of native C
> and into js, though a small part of it must remain native to push
> the cookie back to edbrowse and curl and the jar.

Why? If we've got to retain native parts of this I see no particularly good
reason to change it. Just because we *can* change code into a new (to us)
shiny language doesn't necessarily mean we should.

In fact, I'll probably need to role back some of the startwindow stuff as part
of putting together a working DOM. Of course, this isn't confirmed,
and I'd need to see how the new parser looks before I know what needs to be changed.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[Edbrowse-dev] getters and setters in straight javascript

[Karl Dahlke]

It is certainly possible that some of startwindow.js will eventually
have to return to native C,
appendChild and insertBefore in particular, but only if it must.
The advantages of keeping support routines in js are so many and so substantial
I don't even have to list them.
A 4 to 1 code reduction is just one example.

You speak of the day when "we have determined which js engine to use",
as though we will know that the js engine will not need to change again.
I don't have a lot of confidence that day will ever come.
Such things are supported and then not supported.
Even if we do settle on one brand,
mozilla as an example, the next version might
have a completely different api. We've seen that before.
All other things being equal, we would want to minimize
the code that interacts with the js engine.
Call it insurance if you will.

As per the URL setters, these had a lot of c++ strings in them,
which is why I ran into them in the first place.
We were going to have to convert this code back to C strings
if it remained native, so I did an easier conversion,
that may stand or may not.

Yes I agree there isn't much point in moving the document.cookie setter,
it's not that much code, it is straight C, it works,
and some of it has to be native anyways.
The other setters are equally straightforward, and can remain native.

So ok, having removed over 1,000 lines from jseng-moz.cpp,
and having converted the remaining c++ strings to c,
Adam I think we are finally go for launch.
Create jseng-duk.c, and I hope it works, and works well, and works cleanly.
After a small amount of research, Chris is pretty optimistic.
It looks a lot easier to work with than the mozilla beast
we've been wrangling with thus far. But only time will tell.

Karl Dahlke

Re: [Edbrowse-dev] getters and setters in straight javascript

[Adam Thompson]

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

On Sun, Jun 14, 2015 at 11:04:21AM -0400, Karl Dahlke wrote:
> It is certainly possible that some of startwindow.js will eventually
> have to return to native C,
> appendChild and insertBefore in particular, but only if it must.
> The advantages of keeping support routines in js are so many and so substantial
> I don't even have to list them.
> A 4 to 1 code reduction is just one example.

I agree that the code reduction is nice as is the fact that,
so long as it's standard ECMA script we're more or less engine independant,
however I'd also make the point that *some* of that code was probably down to
the nature of the mozilla engine and that we need to be careful that,
at the end of this, we have a compliant DOM.

> You speak of the day when "we have determined which js engine to use",
> as though we will know that the js engine will not need to change again.
> I don't have a lot of confidence that day will ever come.
> Such things are supported and then not supported.
> Even if we do settle on one brand,
> mozilla as an example, the next version might
> have a completely different api. We've seen that before.
> All other things being equal, we would want to minimize
> the code that interacts with the js engine.
> Call it insurance if you will.

I agree, but one of my biggest problems with mozilla as a js engine is the
constant, incompatible, changes in the API.
That's one of the things I like with Duktape in that it's a js engine first and
foremost and isn't subject to the demands of a specific browser.

In addition, as we move the DOM into the js process (which'll probably have to
happen at some stage), we'll find that some of this stuff becomes easier since
the support code will already be written as part of putting together the tidy5 DOM
(at least I expect it will... though that's down to how Chris writes the new parser logic).

> As per the URL setters, these had a lot of c++ strings in them,
> which is why I ran into them in the first place.
> We were going to have to convert this code back to C strings
> if it remained native, so I did an easier conversion,
> that may stand or may not.

Yes, thanks for putting in the work here,
and appologies if I sound ungreatful,
I'm just concerned that we don't inadvertantly lose functionality or create
future problems.

> Yes I agree there isn't much point in moving the document.cookie setter,
> it's not that much code, it is straight C, it works,
> and some of it has to be native anyways.
> The other setters are equally straightforward, and can remain native.
> 
> So ok, having removed over 1,000 lines from jseng-moz.cpp,
> and having converted the remaining c++ strings to c,
> Adam I think we are finally go for launch.
> Create jseng-duk.c, and I hope it works, and works well, and works cleanly.
> After a small amount of research, Chris is pretty optimistic.
> It looks a lot easier to work with than the mozilla beast
> we've been wrangling with thus far. But only time will tell.

Indeed and the usage model seems to fit more neatly into ours.
I'm hoping to be able to put in some real work on this this weekend.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]