00:00:14  * Fishrock123quit (Remote host closed the connection)
00:16:48  * paulfryzeljoined
00:22:05  * Fishrock123joined
00:52:58  * AtumTquit (Remote host closed the connection)
00:56:13  * Fishrock123quit (Remote host closed the connection)
01:02:49  * Fishrock123joined
01:17:03  * Fishrock123quit (Remote host closed the connection)
01:29:05  * gibson042joined
01:35:15  * not-an-aardvarkjoined
01:42:16  * dilijevquit (Quit: Connection closed for inactivity)
02:00:38  * caridyquit (Remote host closed the connection)
02:01:05  * caridyjoined
03:52:34  * jmdyckquit (Quit: Leaving.)
03:54:02  * gibson042quit (Quit: Leaving.)
05:18:58  * gskachkovquit (Quit: gskachkov)
05:39:59  * gskachkovjoined
05:47:45  * gskachkovquit (Ping timeout: 258 seconds)
06:15:34  * basicdaysquit (Ping timeout: 276 seconds)
06:29:40  * basicdaysjoined
06:54:40  * gskachkovjoined
07:40:03  <TabAtkins>Is nice.
07:49:16  <annevk>Not seeing it even after refresh...
07:50:35  <ljharb>annevk: `no`?
07:51:06  <annevk>ljharb: lots of ` there
07:51:11  <ljharb>huh, weird
07:51:36  <annevk>Maybe it hasn't rolled out to corporate IRCCloud?
07:51:48  <ljharb>oh maybe so, what's corporate irccloud?
07:52:19  <annevk>ljharb: well I go to irccloud.mozilla.com, not entirely sure who ends up hosting the instance though and how that gets updated
07:52:27  <ljharb>ah k
07:55:20  <TabAtkins>Oh, huh, I just have a corporate-backed account on irccloud.com. I wonder why Moz runs its own?
07:58:17  <annevk>TabAtkins: I suspect so we can use our own authentication mechanism and maybe some privacy and data ownership things, dunno really
08:21:13  <littledan>ljharb: Yes, we were talking about why those can't coexist
08:23:17  <ljharb>littledan: gotcha. is it just a matter of defining whether `x.#foo` attempts to look up the slot for `this.constructor.#foo` before or after it attempts to look up the slot for `this.#foo`?
08:23:44  <ljharb>i guess that would mean that it would always throw for one of them, and therein lies the rub
08:23:56  <littledan>no, the concern isn't about the receiver (it would never use a different receiver if one is explicitly provided) but about the private name
08:24:51  <ljharb>hm
08:25:59  <ljharb>so given `class X { #foo = 3; static #foo = 4; get() { return this.#foo; } static get() { return this.#foo; } }` - `new X().get()` vs `X.get()`, as opposed to `X.prototype.get.call(x)` vs `X.get.call(new X())`?
08:26:11  <ljharb>iow the first pair is the intuitive one, but the second pair is where it gets tricky?
08:27:10  <ljharb>(just making sure i understand the conflict)
08:33:29  <littledan>it's not about intuitive vs tricky, it's like, I was trying to understand the semantics that jeffmo was proposing at all
08:33:53  <littledan>the currently specified semantics are that each private declaration creates a private name which is bound in lexical scope. How would you do that if there are two of them?
08:34:22  <littledan>I can imagine some semantics (they get the same private name)--this has some implications which are a little funny
08:34:31  <littledan>I think we could leave that generalization for a future change
08:35:50  <ljharb>hm
08:36:12  <ljharb>could you name the static ones with a "static:" prefix?
08:36:16  <ljharb>like "static:foo" vs "foo"
08:49:03  <littledan>huh, you mean like you'd do this.#static:foo ?
08:49:13  <littledan>if you use static_ as your prefix, you can already do that!
08:49:18  <littledan>and then have "overlapping" names
08:49:34  <littledan>`class C { static #static_foo; #foo; }
08:49:39  <littledan>`class C { static #static_foo; #foo; }`
08:49:43  <littledan>this is permitted already!
09:01:14  <ljharb>no
09:01:34  <ljharb>i mean like internally, private fields in a static context would get a different name
09:01:57  <ljharb>iow in my class X example above, the one inside "static get" is statically distinct from the one inside "get"
09:07:26  <littledan>I don't know how you'd resolve `x.#y` to know whether it is talking about the static or instance name
09:07:39  <littledan>since a method can be called with anything as the receiver
10:14:57  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
10:25:10  * mylesborinsquit (Quit: farewell for now)
10:25:41  * mylesborinsjoined
11:33:26  * jmdyckjoined
13:31:47  * bradleymeckjoined
13:39:44  * howdoiquit (Quit: Connection closed for inactivity)
13:41:33  * isHavvyGhostingjoined
13:44:28  * isHavvyquit (Ping timeout: 240 seconds)
13:53:46  * AtumTjoined
14:01:10  * Fishrock123joined
14:18:58  * caridyquit (Remote host closed the connection)
14:19:48  * caridyjoined
14:23:53  * Fishrock123quit (Remote host closed the connection)
14:38:41  * Fishrock123joined
14:46:47  * Fishrock123quit (Remote host closed the connection)
15:34:48  * bradleymeckquit (Quit: bradleymeck)
15:38:51  * gskachkovquit (Quit: gskachkov)
15:53:33  * Fishrock123joined
16:05:06  * howdoijoined
16:05:25  * bradleymeckjoined
16:14:26  * Fishrock123quit (Remote host closed the connection)
16:16:39  <ljharb>littledan: based on the context of the method itself
16:16:48  <ljharb>littledan: static methods can access static fields, instance methods instance fields
16:17:11  <ljharb>i do see how that'd be a problem if you wanted a static method that could access an instance field
16:17:49  <littledan>the current proposal avoids doing this sort of thing. For example, a static method could have a function defined inside of it, which is used as a callback with instances as the receiver
16:18:10  <littledan>or, a static initializer could create an instance, and then read a private field from that instance
16:18:40  <ljharb>right, makes sense
16:18:45  <ljharb>k, i think i understand the problem :-)
16:20:48  * bradleymeckquit (Quit: bradleymeck)
16:42:57  * gskachkovjoined
16:47:54  * Fishrock123joined
17:03:51  * gskachkovquit (Quit: gskachkov)
17:04:46  * bradleymeckjoined
17:07:35  * gskachkovjoined
17:10:44  * gskachkovquit (Client Quit)
17:13:24  * gskachkovjoined
17:17:26  * gskachkovquit (Client Quit)
17:23:55  * caridy_joined
17:26:08  * caridyquit (Ping timeout: 260 seconds)
17:32:50  * basicdaysquit (Ping timeout: 240 seconds)
17:39:11  * basicdaysjoined
17:54:17  * gskachkovjoined
18:08:41  * basicdaysquit (Ping timeout: 255 seconds)
18:12:34  * dilijevjoined
18:12:45  * basicdaysjoined
18:38:02  <Bakkot>yeah, I fully support the current "can only have either a static private or instance private field of a given name", unless and until we someday come up with a better solution. it is a little surprising coming from other languages, but it feels like an inevitable consequence of the scope-based privacy model we're going with.
19:18:55  * Fishrock123quit (Remote host closed the connection)
19:37:39  * howdoiquit (Quit: Connection closed for inactivity)
19:48:14  * gskachkovquit (Quit: gskachkov)
19:55:12  * gskachkovjoined
20:13:44  * gskachkovquit (Quit: gskachkov)
20:16:55  * gskachkovjoined
20:21:29  * Fishrock123joined
20:40:53  * Fishrock123quit (Remote host closed the connection)
20:46:48  * Fishrock123joined
21:10:03  * bradleymeckquit (Quit: bradleymeck)
21:22:28  * Fishrock123quit (Remote host closed the connection)
21:35:00  * Fishrock123joined
21:58:54  * AtumT_joined
22:01:20  * AtumTquit (Ping timeout: 255 seconds)
22:12:47  * AtumT_quit (Ping timeout: 260 seconds)
22:45:01  * Fishrock123quit (Remote host closed the connection)