edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
* [Edbrowse-dev] obj = new Foo()
@ 2017-07-05 13:50 Karl Dahlke
  2017-07-05 15:01 ` Chris Brannon
  2017-07-05 21:13 ` Kevin Carhart
  0 siblings, 2 replies; 3+ messages in thread
From: Karl Dahlke @ 2017-07-05 13:50 UTC (permalink / raw)
  To: Edbrowse-dev

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

After playing with duktape for a couple days I'm about as far up the learning curve as I was after a month of moz js.
In other words, moz is ungodly complicated, while duktape is clear and simple.
Neither is particularly readable or compact however, but at least duktape is straightforward, like cobol, where you write

add a to b giving c;

instead of

c = a + b;

So it's clunky, and takes an entire page of code to do something pretty obvious, but you can read it through without getting a headache, and you can write it without too much strain on the brain.
More important, you don't get a segmentation fault one time in 100, nearly impossible to debug, because you didn't root some value on your C stack and the mozilla garbage collector came along and removed it just before you used it, or you didn't autocompartment something properly, etc etc.
The moz api just cries out for catastrophic and irreproducible bugs.
I worked very hard to eliminate those kinds of bugs on the last rewrite, e.g. one entry point that sets the autocompartment, so at least you know you got that right, and rooting or handling everything else everywhere.
Well guess what, we don't have to worry about any of that shit in duktape!
If we get duktape working, and if jsrt passes, and it meets our needs, I don't think we'll ever go back to mozilla.
I can't imagine going back to mozilla.
I don't like to talk about burning bridges, but lordy the difference is like night and day, and I don't think we'd ever go back.
Which leads to my next question / observation.

You can define a class in C or in js.
I gave an example of the TextNode class in an earlier email.

TextNode = function() {
this.data = '';
if(arguments.length > 0) this.data += arguments[0];
}

This is a simple class with no setters, no side effects, and no particular reason to write it in C.
And of course it's 5 lines of js, and 40 lines of unportable C in either mozilla or duktape, since, as I say, both APIs make for long and wordy code.
So the advantage of js over c remains.
But here's the difference.

In mozilla or duktape, a class defined in C can be instantiated in c or in js - as you would expect.
In duktape, a class defined in js (as shown above) can be instantiated in c or in js, as you might expect, (I just tested this and it works), but this is not the case for mozilla.
A class defined in js cannot be directly instantiated from c.
You have to write something really ugly like

js_rooted_value val = js_execute("new TextNode('elephant')");
js_rooted_object my_text_object = js_value_to_object(val);
// Thus capturing the instantiated object.

Well that works fine, but your brain has to leave the c world, run some js code, and then jump back to c.
Also terribly inefficient if there are a lot of these, and if performance matters.
You can imagine calling up the js interpreter, running the js code, going back to c, over and over again, etc.
So there are a lot of classes that I left in c, because I needed to instantiate them in c, and I didn't want a bunch of circuitous code as shown above.
But then I have tons of unreadable, unportable, mozilla specific ugly c code to build some pretty simple classes and methods.
Now, on the brink of converting to duktape ... should I take advantage of the feature that duktape offers, a feature that every engine should offer in my opinion,
that I can instantiate any class, whether created in c or in js, using either c or js code, and it all works seamlessly?
I tell you, it would make things soooooooo much easier.
But it would make it a little bit harder to go back to mozilla 5 years from now if we felt we had to do that.
Not impossible, as illustrated by the js_execute("new TextNode") code shown above, but a bit more awkward to go back.

Personally I stand ready to march on and take advantage of this feature, thus simplifying the code considerably, because I don't think we're ever going back,
but if you-all can convince me that's a bad idea, then I guess I could leave a bunch of classes in C, where they are now, even though they're pure and simple and could easily be in js instead.
You'll have to do some fast talking though.
If I'm the one doing the conversion I'll want to clean things up along the way, and duktape makes that possible.
In other words, I've almost made my mind up already, but I'm trying not to be a dictator about things, so opening it up for discussion.

On a psychological note - depression saps all my energy, wherein the last thing I want to do is program, but if I start programming it helps with depression.
Kinda like exercise I guess.

Karl Dahlke

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Edbrowse-dev] obj = new Foo()
  2017-07-05 13:50 [Edbrowse-dev] obj = new Foo() Karl Dahlke
@ 2017-07-05 15:01 ` Chris Brannon
  2017-07-05 21:13 ` Kevin Carhart
  1 sibling, 0 replies; 3+ messages in thread
From: Chris Brannon @ 2017-07-05 15:01 UTC (permalink / raw)
  To: Edbrowse-dev

Karl Dahlke <eklhad@comcast.net> writes:

> If we get duktape working, and if jsrt passes, and it meets our needs, I don't think we'll ever go back to mozilla.
> I can't imagine going back to mozilla.

I can't imagine a really compelling reason to switch again, either.

> but if you-all can convince me that's a bad idea, then I guess I could
> leave a bunch of classes in C, where they are now, even though they're
> pure and simple and could easily be in js instead.

The main arguments for and against moving classes into JS have already
been made on this list.  And if we ever do have to switch away from
Duktape for some reason, that switch is going to be painful,
regardless of whether the code is in C or JS.
So I don't think I can convince you.

-- Chris

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Edbrowse-dev] obj = new Foo()
  2017-07-05 13:50 [Edbrowse-dev] obj = new Foo() Karl Dahlke
  2017-07-05 15:01 ` Chris Brannon
@ 2017-07-05 21:13 ` Kevin Carhart
  1 sibling, 0 replies; 3+ messages in thread
From: Kevin Carhart @ 2017-07-05 21:13 UTC (permalink / raw)
  To: Karl Dahlke; +Cc: Edbrowse-dev



I am agnostic.  I remember the cumbersome embedding like

>
> js_rooted_value val = js_execute("new TextNode('elephant')");
> js_rooted_object my_text_object = js_value_to_object(val);
> // Thus capturing the instantiated object.

>From the xhr routine and other routines.  But I tend to mostly work on
DOM, so it doesn't matter as far as I am concerned.  I doubt we would want 
to go back to moz.  Maybe one danger that comes to mind is that 'duktape' 
becomes a ghost town.  I notice they have thriving and frequent commits 
right now: 15 days ago, 6 days ago, 2 months ago.  It's actively 
maintained right now, but this can change.  However, I don't think my 
concern is any worse than the chaos of Mozilla yanking people around with 
changes.

Kevin

PS Welcome Dominique.  Given your expertise it seems like you will come up 
with some useful contributions, if you have time.  I'm in favor of masking 
out passwords.  It seems non standard not to do it, and I always worried 
about someone peeking over the user's shoulder.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2017-07-05 21:12 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-07-05 13:50 [Edbrowse-dev] obj = new Foo() Karl Dahlke
2017-07-05 15:01 ` Chris Brannon
2017-07-05 21:13 ` Kevin Carhart

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).