00:35:23  * AtumTquit (Remote host closed the connection)
03:28:02  * plutoniixjoined
07:50:05  * plutoniixquit (Quit: Leaving)
10:25:08  * mylesborinsquit (Quit: farewell for now)
10:25:39  * mylesborinsjoined
10:35:54  * AtumTjoined
13:42:21  <caitp>bradleymeck: I'm not totally sure we were talking about the same thing with "rooted"? I was talking about the composite store being rooted
13:42:57  <caitp>and I was thinking, if you let users create their own composite stores, they'd have to be able to create their own roots
13:43:14  <caitp>stuff that can outlive the global context, which is probably a horrible idea
13:43:52  <caitp>but yeah I'm not that familiar with the proposal so don't take anything I'm sayin too seriously :D
13:44:56  <bradleymeck>ah
13:45:53  <bradleymeck>caitp: I was being fuzzy with term "rooted", my example just changes from the root being the GC root outside of any given global to being tied to a specific global
13:47:31  <bradleymeck>tied to but not really placed there in a special way
13:50:15  <caitp>yeah, I guess if the user is creating their own stores, the whole cross-realm thing is a moot point so long as other realms can still access their store
13:50:32  <caitp>so it doesn't really need to be a gc root
13:51:09  <caitp>but, it's important if the proposal is just "give them a function to make a rich key", because then they don't reference any specific key store
13:52:22  <bradleymeck>caitp: can you clarify, because that is what the proposal currently is and doesn't force them to use a specific store
13:52:48  <bradleymeck>the key is opaque though so can't extract meaningful info from just obtaining the key
13:54:24  <caitp>yesterday I was saying "well heck why not just let useres make their own composite collections" which is similar to making their own composite key stores
13:56:03  <caitp>and I added something like "well I guess all of these collections would need to be gc rooted for the cross-realm aspect", but that's nonsense
13:56:14  <caitp>I'm just saying I admit what I was saying did not make sense.
13:58:15  <bradleymeck>mmm i think it made sense, but then again you are an implementer (insert ent picture from lord of the rings)
13:58:27  <bradleymeck>i don't have insight to certain bits of how machinery works
13:58:56  <caitp>I think letting a user create as many GC roots as they want is probably a very bad idea, since they're basically constrained by the lifetime of the Isolate
13:59:09  <caitp>very abusable thing to do
13:59:14  <caitp>so, you wouldn't want that :x
14:05:20  <caitp>I guess the thing you might want in some cases, is `let key1 = compositeKey(a, b), key2 = compositeKey(a, b); key1 !== key2`
14:05:39  <bradleymeck>why?
14:05:48  <caitp>if I understand it, in this proposal, compositeKey() has getOrCreate semantics
14:05:55  <bradleymeck>yep
14:06:04  <caitp>but, what if you want the same composite collection to produce distinct keys in some cases
14:06:15  <caitp>I don't know why, I'm sure someone has a need for that
14:06:26  <bradleymeck>use a sentinel first argument for each different distinct case
14:06:37  <bradleymeck>let key1 = compositeKey(1, a, b), key2 = compositeKey(2, a, b); key1 !== key2
14:06:55  <bradleymeck>you could do it in other positions too, but that gets weird
14:07:03  <caitp>"but bradley, your proposal says to throw a TypeError if you pass an Smi to compositeKey()!"
14:07:06  <caitp>kidding
14:07:27  <bradleymeck>caitp: it shouldn't as long as a or b are able to be weakmap keys
14:07:45  <bradleymeck>you just need to associate 1+ lifetimes with a Key 0 lifetimes with a Symbol
14:08:10  <bradleymeck>we could change Key to have 0 lifetimes requires but that seems at odds with how it should be used
14:08:12  <caitp>maybe I misread the polyfill
14:08:20  <caitp>I thought it was "if any argument is a primitive, throw"
14:08:37  <bradleymeck>no, that would make it very complicated for some things like the above
14:08:59  <bradleymeck>it does a loop to find referential parts, makes a weakmap trie path using those
14:09:13  <bradleymeck>then it makes a strong map path with the non-referential primitive parts
14:09:17  <caitp>well you'd probably have like a `const sentinelForMyModule = {};` and use that
14:09:29  <caitp>I guess that's not super horrible
14:09:58  <bradleymeck>not horrible but unclear on why it needs to be all objects
14:10:17  <bradleymeck>primitives have one nasty bit that they can keep things alive for a long time if you have an immortal object
14:10:40  <bradleymeck>compositeKey(global, 1) is... leaky
14:10:53  <bradleymeck>but so is compositeKey(compositeKey)... so 🤷
14:11:21  <caitp>I'm not sure how it's leaky, since the composite store wouldn't retain the global
14:11:41  <caitp>(assuming global is "global object"
14:11:43  <caitp>)
14:12:27  <caitp>one thing that might be nice is an optional serialization value for these keys, for debugging you know/
14:12:28  <caitp>?
14:13:09  <caitp>I can just imagine being the hapless programmer trying to figure out what a particular key was for in devtools
14:13:38  <bradleymeck>caitp: as long as that serialization isn't exposed to userland that isn't bad
14:14:18  <bradleymeck>caitp: the above are leaky in the sense that as long as the global is alive, that path will be alive, and as long as compositeKey is alive that path is alive
14:14:49  <bradleymeck>you would need to destroy the global to free that path which seems like an unlikely intent
14:15:31  <bradleymeck>caitp: is there any reason that devtools couldn't just show the path to the key?
14:16:18  <bradleymeck>this does give my ideas for my debugger though...
14:16:24  <caitp>well, I'm sure it could, but more than likely you end up with a bunch of components that look identical
14:16:30  <caitp>not very good instance granularity
14:16:30  <bradleymeck>like why can't we just attach random debugger data to references
14:17:46  <bradleymeck>caitp: idk, most of my debugging workflows end up with tons of components that look similar
14:18:14  <bradleymeck>also you could just do stuff like `compositeKey(user, `${user.email}`); to add descriptions to the path
14:21:35  <bradleymeck>there are some really weird things you can do with that fn though which are... uggg
14:22:35  <bradleymeck>const key_with_lifetime_of_a_and_b = compositeKey(compositeKey(a), b)
14:23:16  <bradleymeck>and if WeakRefs land... it gets really interesting
14:40:01  <caitp>how is `compositeKey(compositeKey(a), b)` different from `compositeKey(a, b)`? since the thing from `compositeKey(a)`? `compositeKey(a)` would be orphaned when `a` is collected, so it's sort of the same as `a` being orphaned, just the timing is subtly different?
14:42:29  <bradleymeck>well we don't unwrap the `compositeKey(a)` so technically it is tied to that lifetime not `a` but `compositeKey(a)` is tied to `a`'s lifetime
14:42:55  <bradleymeck>if someone saved `compositeKey(a)` to a variable it could keep `compositeKey(compositeKey(a), b)`'s path alive
14:43:06  <bradleymeck>which is... :-/
14:43:18  <bradleymeck>but I think unwrapping has worse effects
14:43:43  <caitp>what I'm saying is, if `compositeKey(a)` dies when a dies, and compositeKey(compositeKey(a), b) dies when compositeKey(a) dies, then doesn't compositeKey(compositeKey(a), b) die when a dies?
14:43:56  <caitp>since compositeKey(a) isn't kept alive by anything in that particular example
14:44:04  <bradleymeck>caitp: yes
14:44:17  <bradleymeck>keys die when any of their components die
14:44:24  <bradleymeck>path to keys die*
14:44:35  <caitp>right, so I was just wondering how it's weird :p
14:44:52  <caitp>unless compositeKey(a) gets retained beyond the lifetime of a
14:44:57  <caitp>then yes, that kind of breaks things a bit
14:45:39  <bradleymeck>it can be retained past the lifetime of a
14:45:47  <caitp>of course you could keep the world simple by making that illegal
14:45:59  <caitp>"throw a type error if any component part is a composite key"
14:46:00  <bradleymeck>cause people could do `global.yolo = compositeKey(a)`
14:46:23  <bradleymeck>we could throw, but I'm not sure that we need to
14:46:30  <bradleymeck>it is just... weird, not complicated
14:47:12  <bradleymeck>being able to add to an existing key or combine keys to get a larger set of lifetime bounds seems useful
14:47:32  <bradleymeck>well can't add to lifetime of an existing key, make a new key based upon another key*
14:48:27  <caitp>my pov is kind of "weird is a form of complicated"
14:48:36  <caitp>more things to think about
14:49:57  <bradleymeck>making exceptions makes things more complicated to me
14:50:00  <bradleymeck>more things to know
14:50:17  <bradleymeck>having something be weird but act the same as anything else seems easier to learn
14:51:01  <bradleymeck>but... I also am still in love with control flow graphs like google draw lets you do (not compiler stuff), more branches makes things much more complicated in those
14:52:07  <caitp>I think it's a different way of approaching problem solving --- the error paths are good for like real-time blind programming
14:52:16  <caitp>"oh lets do this --- oh I can't, better try this other approach"
14:52:33  <caitp>where the more open-ended way means everything "works" and you have to spend more time finding the best way to do it
14:52:51  <caitp>instead of having something sort of prescribed
14:53:18  <bradleymeck>if there was a reason to prevent doing it that was more concrete than it being "weird", it seems fine to enforce
14:53:29  <bradleymeck>since it is an error, could even make it not an error in the future
14:53:46  <bradleymeck>otherwise it would act as a testing fn for if something is a compositeKey, which is a bit odd in itself
14:54:17  <caitp>I'm not sure there's any reason to not expose that something is a composite key, does it matter?
14:54:36  <bradleymeck>idk
14:54:51  <bradleymeck>but idk if there is any reason to prevent parts from being a composite key either
14:54:57  <caitp>if there's a security reason to hide it, that sesems like the wrong kind of security
14:55:08  <caitp>*shrug*
14:56:28  <bradleymeck>caitp: i'm not sure about security, but it does mean that polyfills have to consider this cross realm, but cross realm anything with polyfills is nightmares anyway
14:57:11  <bradleymeck>weakref on someone elses composite key to test finalization exposes the lifetime of the inner part which is a bit concerning
14:58:55  <bradleymeck>that might be true even w/o nesting...
15:02:20  <caitp>I should probably get back to work on the class fields stuff, but it's an interesting discussion :)
15:05:47  <bradleymeck>made tracking issue thanks to this convo https://github.com/bmeck/proposal-richer-keys/issues/3
15:23:52  <mmarchini>is there any way inside V8 to know if a JSObject is a class (`class Foo() {}`) or an instance (`let foo = new Foo()`)?
15:24:09  <mmarchini>any flags or bit fields?
15:24:47  <bradleymeck>mmarchini: you can check IsConstructor()
15:29:37  <caitp>SharedFunctionInfo has a IsClassConstructorBit, the api might expose that somewhere
15:30:10  <caitp>if the es6 class-ness is important
15:42:38  <mmarchini>The bit is set on instances as well :(
15:42:57  <mmarchini>For context: I'm trying to distinguish between classes and instances on llnode
15:43:14  <mmarchini>bradleymeck: thanks, I'll look into it later
15:43:19  <caitp>that's a bit strane
15:43:34  <caitp>how is the bit set on instances, it's part of SharedFunctionInfo
15:43:40  <caitp>which is only connected to instances of a function
15:44:44  <mmarchini>I mean, if you follow the constructor_or_backpointer tree in the instance map, you'll get the class constructor, which will have the bit set
15:45:37  <caitp>if you're working with the api you shouldn't be dealing with maps (or SFI) at all, though?
15:46:03  <mmarchini>llnode accesses internal stuff, so not dealing with the API
16:41:29  * RT|Chatzillaquit (Quit: ChatZilla [Firefox])
17:32:34  * seventhjoined
18:12:39  <rwaldron>mathiasbynens ping https://github.com/GoogleChromeLabs/jsvu/issues/40
19:46:07  * seventhquit (Remote host closed the connection)
22:22:52  * RT|Chatzillajoined