| 00:23 | <rbuckton> | rbuckton: will you be in tokyo btw? |
| 00:24 | <rbuckton> | wait a second, isn't there a pretty simple solution to the communication channel problem? if the key to the shared global registry is the combination of source location + |
| 00:25 | <rbuckton> | Or are you just talking about the path to the file, not position within the source text? |
| 00:29 | <rbuckton> | I have to think more on that. When I raised the suggestion it was to key purely off of source location (path + line/character). This makes them non-bundleable however. The point of with identity was to allow a bundler with whole program knowledge and a list of entrypoints to be able to perform tree shaking, concatenation, module hoisting, and all of the other various tricks they do, and have two optimally minimized bundle files be able to identify the same shared struct using something other than source location. |
| 00:34 | <shu> | Or are you just talking about the path to the file, not position within the source text? |
| 00:35 | <shu> | like just change the semantics of the registered modifier or with registered or whatever we choose to key off of location, add the caveat about bundling, done |
| 00:36 | <shu> | seems totally reasonable to me to have the bundling guidance to be "source location is meaningful for these things, like template strings" |
| 00:37 | <rbuckton> | If the key is the source location and the module itself cannot be reevaluated (NodeJS does some shenanigans here in CJS), then it would be unforgeable. with identity is difficult to forge if you don't allow it to be used in eval, since it has to be encoded as source text. |
| 00:38 | <rbuckton> | like just change the semantics of the |
| 00:38 | <shu> | how do they deal with template strings? |
| 00:39 | <rbuckton> | brb |
| 00:40 | <shu> | anyway i remain steadfast of the opinion this is not a design blocker |
| 00:41 | <shu> | If the key is the source location and the module itself cannot be reevaluated (NodeJS does some shenanigans here in CJS), then it would be unforgeable. |
| 00:42 | <rbuckton> | how do they deal with template strings? |
| 00:42 | <shu> | rbuckton: the part where they are keyed off of their location: https://tc39.es/ecma262/#sec-gettemplateobject |
| 00:44 | <shu> | so if you, like, inline the contents of a function that uses a template object into two different call sites, now you have different semantics |
| 00:44 | <shu> | i'm just pointing it out as an example of a thing we have already that is keyed off of location, that bundlers need to be aware of |
| 00:44 | <shu> | this will be another thing, but it's not new-in-kind |
| 00:45 | <rbuckton> | Not sure? It's a bit of an esoteric thing to depend on, other than it not being reevaluated each time. It's be surprised if it's that common to address it |
| 00:46 | <shu> | well, okay. i feel pretty good about providing bundling guidance instead of treating it as a hard design constraint |
| 00:46 | <shu> | that is, i feel pretty good now about the overall package of an unforgeable-in-practice (unless you trigger reevaluations) registry that uses locations to auto-correlate + bundling guidance as the leading solution |
| 00:47 | <shu> | okay gotta sign off, been working since 7am, be back tomorrow |
| 00:47 | <rbuckton> | An incorrect reference identity for a template strings array doesn't come up anywhere near as often as i imagine use of methods on shared structs will. |
| 00:48 | <shu> | yeah, bundlers need to lift all those definitions to a different file, and tree shake the ones that are only ever used in a single thread and thus never need correlation |
| 00:48 | <shu> | i do not hear a counterargument that that is somehow a dealbreaker |
| 05:56 | <Ashley Claymore> | My point is more that, if we actually baked multithreading into the language, such that you don't have to spin up a copy of your application and could just use existing references, then we wouldn't have the correlation issue. We'd have other issues instead, but they are the pretty much the same issues as any other language with multithreading. While clearly a challenge; I like that JS starts from isolated memory and builds message passing and shared memory on top as opt-in and scoped. compared to languages that instead share everything from the start. |
| 05:59 | <Ashley Claymore> | If `Object` (and basically everything) itself wasn't mutable would maybe have made things like sharing closures more tenable, but that bridge has closed |
| 12:23 | <Mathieu Hofman> | Has it? Moddable's XS shows some behavior sharing is possible with their full marshalling between frozen realms |
| 13:25 | <Ashley Claymore> | I mean for the most common places. Things definitely get a bit simpler if everything can be frozen! |
| 13:26 | <Ashley Claymore> | Lots of XS is in ROM, that's the easiest thing to share ;) |
| 13:34 | <Mathieu Hofman> | What I'm wondering is if the use cases for shared struct with behavior are compatible with frozen realms. Setup your realm and shared behaviors, freeze, then fork |
| 15:21 | <shu> | frozen realms is a not a mass adoptable strategy, but i see no reason why shared structs cannot compose with frozen realms |
| 15:27 | <Mathieu Hofman> | I don't exactly want shared memory concurrency to be mass adopted either... |
| 15:30 | <shu> | it... won't be? |
| 15:31 | <shu> | this is advanced capability opt-in not just on the API level but on the server config level |
| 15:31 | <shu> | cross-origin isolation and all that |
| 15:31 | <shu> | the stance of the web platform is you cannot, by default, do anything with shared memory unless you jump through many opt-in hoops |
| 15:32 | <shu> | and note i did not i say "i don't want frozen realms to be mass adopted" |
| 15:32 | <shu> | i said it's not mass adoptable |
| 15:34 | <shu> | i've also laid out in the past how you can use shared struct's underlying shared memory-ness without cross-origin isolation if you give up mutability |
| 15:34 | <shu> | i just don't think that goes far enough for the advanced apps that actually need mutability |
| 15:34 | <shu> | but immutable shared memory is certainly possible to be mass adopted |
| 16:15 | <Mathieu Hofman> | I think I probably didn't express myself correctly. I'm wondering if a frozen realm is too much of a hoop to jump through for the kind of applications that want shared structs with behavior, since those already need to jump through hoops. If it were an acceptable hoop, maybe it could be the basis of a solution for behavior sharing. |
| 16:59 | <shu> | yes, a frozen realm is too much of a hoop to jump through for the advanced product app partners i am developing this in conjunction with |