/#!/JoePea (2018-04-15T18:10:43.000Z)
trusktr at gmail.com (2018-04-15T19:20:31.576Z)
> GATEWAY That's an interesting idea, Bradley, thanks! I originally wanted this for implementing "protected" class members (i.e. sharing a WeakMap across subclasses in different files), but I've since done this another way that is even better: https://github.com/trusktr/lowclass. With lowclass we can also make what I'm calling "module protected" access (similar to "friends" in C or "package protected" in Java) by simply leaking access helpers to outside scope inside a module. Here's the example in the README <https://github.com/trusktr/lowclass#friends-like-in-c-or-package-protected-like-in-java> . But now that I've revisited this thread, I realize that with a GATEWAY it is possible to share a "leaked" access helper across files too, thus making something that is more like Java's "package protected"! Cool! > note: all dependencies of these modules could access GATEWAY This can be prevented by having the `GATEWAY` function count how many times it is called. If we hard code the number of modules that will call GATEWAY in a project, we can throw an error if the number of accesses is higher than expected and blatantly breaking an app to force people not to do it. Automated tests can ensure that the number is hard coded properly. It could also be possible to add a build step to automatically detect and add the hard-coded number. > With Realms That's also interesting, but I think it would be too heavy-weight to create new JS contexts just for sharing some private references. The GATEWAY idea I think is much slimmer. Plus sharing across Realms can introduce all sorts of other problems like `instanceof` checks failing due to one global not being the same reference to the equivalent global in the other realm (`console.assert(window.Object !== realm.Object)`). Here's is the same problem with Jest <https://github.com/facebook/jest/issues/5946> (with Node's `vm` rather than Realms, but essentially its the same issue). It'd be better if there were some sort of spec added to Modules that allowed some set of modules to import private exports from each other with simple syntax, or similar. Maybe it would be based on folder structure, or maybe module identifiers referenced in each other so that there's no physical circular dependency, only harmless circular mentioning of each other at worst, so that runtime circular dependency issues <https://esdiscuss.org/topic/how-to-solve-this-basic-es6-module-circular-dependency-problem> don't become a problem. > If you are interested to look at it, I’ve implemented a module loader with a secret shared across the Doodad framework Thanks for sharing that Claude. It's interesting to see how others are implementing public/protected/private for their classes. :)