Message from JavaScript discussions

June 2017

— Headers work better as objects, but heh

—

I usually combine it with the revealing module pattern in several scope layers, in which the innermost layer can access a single object containing all members, then the next highest scope gets a different object with references to only the public members.

Like this, in a factory:

 
var self = {};
self.private = {
  hello: "world"
};
self.public = {
  what: "is up?"
};
var combined = Object.assign({}, self.public, self.private);

In a large framework I then return combined to the next highest scope which may contain the friend classes or the event bus to them, then return public to a userspace scope (the original caller).

— So in a class instantistion there may be multiple objects flying around in the background, while the user only gets the public one. This usually requires special thunks instead of letting the user instantiate the classes directly

Message permanent page

— Interesting

— Complicated, but interesting

— Heh, I always try to keep my functions tiny

— Like this:

function newThing () {
  var thing = new Thing();
  sendFriends(thing.combined);
  return thing.public;
}

Message permanent page

— I see

— I don't think I've ever had the need to share privates with 'friends' that can't just be public

— And the function definition for the thunk must be scope restricted so that it may see the event bus or friend classes, while the user cannot

Message permanent page

— Heh, in a large framework or library it can get a little crazy

— SendFriends would be an emitter-type pattern?