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. :)
> 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. :) - Joe */#!/*JoePea On Mon, Apr 24, 2017 at 12:34 PM, Bradley Meck <bradley.meck at gmail.com> wrote: > To an extent, yes. You can use hoisting of function declarations and > circular dependencies to create a "gateway". During circular dependencies, > you have a time where function declarations are available but evaluation > has not occured. During that time you can setup your private state. Then, > immediately on evaluation, remove your gateway. > > ``` > // file: ./secrets > > // import all friendly modules (note: all dependencies of these modules > could access GATEWAY) > import './a' > GATEWAY = void 0; > > > // storage for shared secrets > let SECRET; > // gateway > function GATEWAY() { > if (!SECRET) SECRET = {}; > return SECRET; > } > export {GATEWAY}; > ``` > > ``` > // file: ./a > import {GATEWAY} from './secrets'; > if (typeof GATEWAY !== 'function') { > throw Error('import secrets *first*.'); > } > const SECRET = GATEWAY(); > ``` > > With Realms (https://github.com/tc39/proposal-realms) you may be able to > use the completion value of Module Evaluation to also achieve a way to > share private state in a more sane way. VM implementations allow this in > some ways as well : https://github.com/v8/v8/blob/ > a71c338d9e24e55b47125108a0fce754076751d0/include/v8.h#L1109 > > On Sun, Apr 23, 2017 at 6:02 PM, Jordan Harband <ljharb at gmail.com> wrote: > >> Nope. This is exactly why it seems that "protected" couldn't have any way >> to work that has "hard" enforcement. >> >> The only true privacy in JS is via closure (including WeakMaps), or via >> the upcoming "private fields" proposal, assuming it stays as "hard >> private". Anything shared is publicly accessible. >> >> I'd be very interested to hear any idea that would allow modules A and B >> to privately share something, without module C being able to; the only >> thing I could think of would be some sort of private export that explicitly >> included a list of module specifiers that were allowed to import it - which >> would still not be secure whenever loader hooks exist. >> >> On Sun, Apr 23, 2017 at 1:42 PM, /#!/JoePea <joe at trusktr.io> wrote: >> >>> Is there a way to share some secret value across a few modules, and >>> prevent other modules? f.e. prevent modules of an app dev who is importing >>> modules of a library where the library wants to share private stuff across >>> its modules. Is this possible to implement somehow? >>> >>> WeakMaps can be encapsulated inside a module to implement "private" >>> properties for a class defined inside that module and then exported. But >>> "protected" can't be implemented with a WeakMap shared with modules because >>> then end-user app code can import the WeakMap and read all the stuff. Is >>> there some way to share a WeakMap private with classes defined across >>> modules? >>> >>> */#!/*JoePea >>> >>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss at mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180415/d67802f1/attachment.html>