Light

Because it is.

Bear of Very Little Brain

Chatted with ClaudioB earlier. He's planning to set up a machine at home to serve online. I started having a go a few weeks back but got distracted. Setting up #:semem in #:tbox and making it live is my main target today, but as that'll involve poking around on my remote server I might as well have another look then.

Packer

Before any of that, I need to finish a little #:transmission I started last session. repomix has broken on me. As best I can determine, it's down to nodejs version, looks like repomix uses some experimental JSON bits that have been pulled. If that is the case, I could use that thing (?) to choose a version that does work. Faff. I've been meaning to make my own on #:transmissions for a while, this tipped me over. Claude gave me some starter code, I just need to plumb it in and tweak it to sanity, as per Claude code.

transmissions$ ./trans packer ./
...
[Error: ENOENT: no such file or directory, open '/home/danny/github-danny/transmissions/manifest.ttl']

Bum! I didn't get around to sorting out the command-line options.

Good-o! I did start sorting out the command-line options.

Yeah, it looks reasonably well separated. The CLI entry point ./trans calls src/api/cli/run.js which uses yargs - tee hee, they say it best :

Yargs be a node.js library fer hearties tryin' ter parse optstrings.

src/api/cli/run.js then calls src/api/common/CommandUtils.js. That does a little bit of path-splitting and simple logic, calling on src/core/ApplicationManager.js to get things going.

I remember now - I left a bit of refactoring around src/core/ApplicationManager.js in-progress. That's still not a high priority, I'll get to it when I next need to do things around there.

Hmm. The options do look very broken. But shouldn't take much fixing.

Well, you learn something every day. I wanted to check what was considered best practice for privates in JS. I asked Claude, confirmed with Perplexity :

Private Fields in JavaScript

Private fields, denoted by the # prefix, were introduced as part of the ECMAScript 2022 (ES13) specification. This feature provides true privacy encapsulation within classes, preventing access to these fields from outside the class

class Person {
  #secret;
  constructor(secret) {
    this.#secret = secret;
  }
  getSecret() {
    return this.#secret;
  }
}

const person = new Person("my secret");
console.log(person.getSecret()); // "my secret"
console.log(person.#secret); // SyntaxError: Private field '#secret' must be declared in an enclosing class

Supported in:

  • Node.js 12.0.0+
  • Chrome 74+
  • Firefox 90+
  • Safari 14.1+
  • Edge 79+

Closures for Encapsulation

Closures have been a traditional way to achieve encapsulation in JavaScript before the introduction of private class fields

function createCounter() {
  let count = 0;
  return {
    increment: function() {
      count++;
      console.log(count);
    }
  };
}

const counter = createCounter();
counter.increment(); // 1
console.log(counter.count); // undefined

Heh, not sure I've ever used that kind of closure in JS. I can easily imagine my confusion over that syntax. I wouldn't call the private field # syntax pretty, but it's a lot more suitable for this bear of very little brain.

Light