edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Karl Dahlke <eklhad@comcast.net>
To: Edbrowse-dev@lists.the-brannons.com
Subject: [Edbrowse-dev] Removing Shorthand
Date: Mon, 10 Feb 2014 13:26:02 -0500	[thread overview]
Message-ID: <20140110132602.eklhad@comcast.net> (raw)

I hope I am on the right path here.
I find myself, at this point, mostly removing shorthand from html.cpp.
Shorthand like this.

obj *ev = t->jv; /* element variable */

That's the way it use to look.
ev was just shorthand for t->jv,
the javascript variable that goes with this tag.
And not that much shorthand really, it only saves me 3 characters.
But now the shorthand has become longhand.
ev has to be rooted, and that implies a compartment,
so now it looks like this.

AutoCompartmant(cx, jwin);
Rooted(ev, t->jv);

It's now more like longhand, and difficult to read or understand
if you aren't an expert in spider monkey js.
A new developer would look at that and say
"what the hell?"
If I had written my shorthand like this, I could have simply carried it along.

#define e t->jv

With all this in mind, I am removing these shorthand constructs,
and may very well be able to eliinate all Rooted variables
and all AutoCompartments from the html code.
This has the following advantages.

1. More readable.

2. More maintainable.

3. Easier to upgrade when Mozilla changes its api again,
as they surely will.
We likely won't have to mess with html.cpp at all;
it's all contained in js*.cpp. Encapsulation.

4. Easier to switch from Mozilla to some other js engine,
which we might want to do someday if moz continues to be a pain.
Again, html.cpp would mostly be unaffected.

5. All these functions will just work whether js is active or not,
whether cw->jss is null or not.
They aren't setting compartments or rooting variables.
This moves us towards the goal of distroying a context, seting cw->jss = null,
and letting edbrowse march on.

I could put some of the shorthand back, using the #define shown above,
but I usually don't like programming by the preprocessor.
Well we can decide that later.

Karl Dahlke

                 reply	other threads:[~2014-02-10 18:26 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140110132602.eklhad@comcast.net \
    --to=eklhad@comcast.net \
    --cc=Edbrowse-dev@lists.the-brannons.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).