00:00:05  <ljharb>Domenic: the raw form shows <a name>s and looks like a typoed extra >
00:00:56  <rkirsling>I assumed it was for pizzazz 😂
00:01:50  <zkat>It's just a convention I use
00:02:07  * araijoined
00:02:29  <zkat>Habit because it makes API calls stand out so I just do it for a bunch of things 😅
00:03:35  <ljharb>oh lol
00:28:25  * AtumTquit (Remote host closed the connection)
00:39:28  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
01:05:34  * keith_millerjoined
01:10:39  <zkat>(it looks nicer when it's rendered)
01:11:01  <zkat>(but looks very weird in raw .md)
01:13:43  * howdoiquit (Quit: Connection closed for inactivity)
02:51:24  <devsnek>zkat: would `catch (BadError err)` maybe make more sense as `catch (err instanceof BadError)` or something? or is `Type x` already in the pattern matching proposal for instances?
02:56:33  <zkat>That was the original. It didn't work grammatically so I tossed in a glyph
02:56:55  <zkat>And it doesn't quite work how you're saying. It's an extractor, not a type declaration
03:18:52  * cloudshuquit (Quit: Connection closed for inactivity)
03:21:36  * linclark_quit (Quit: Connection closed for inactivity)
03:46:38  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
03:50:40  * cloudshujoined
04:32:27  * jmdyckquit (Remote host closed the connection)
04:34:05  * not-an-aardvarkjoined
05:28:56  <ljharb>personally what we really need is the Builtins.is proposal (with a better name)
05:29:11  <ljharb>`instanceof` is terrible and anything that relies on it is also terrible
05:33:39  <rkirsling>`instanceof` is definitely not good :( I have a library that defines an `isInstanceOf` function just so that I can check instances from a separated unit testing context
07:58:52  * cloudshuquit (Quit: Connection closed for inactivity)
08:09:32  * araiquit (Remote host closed the connection)
08:17:21  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:52:36  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
10:09:43  * araijoined
10:25:07  * mylesborinsquit (Quit: farewell for now)
10:25:38  * mylesborinsjoined
10:32:08  * keith_millerjoined
10:36:52  * keith_millerquit (Client Quit)
11:43:13  * jmdyckjoined
12:48:10  <devsnek>ljharb: +1 to that
12:48:18  <devsnek>maybe that will be my next proposal
12:49:20  <devsnek>is "builtin" the well defined term for stuff like Array and Map and String
12:50:16  <bradleymeck>devsnek: https://github.com/tc39/proposals/blob/master/inactive-proposals.md see James Snell's proposal (he withdrew it)
12:51:36  <devsnek>my idea is to propose that all builtins have a static isX() on them
12:51:52  <devsnek>which does an internal field check and such
12:55:00  <bradleymeck>that is his proposal
12:59:45  <devsnek>i thought his was a global object with .is(x, y)
13:06:09  * AtumTjoined
13:33:42  <bradleymeck>yea, but not really different from putting it on a class
13:33:51  <bradleymeck>putting it on a class means that every new class must have that method
13:49:07  <devsnek>good point
14:41:53  <ljharb> James’s proposal is basically what toStringTag should have been: brand-checking functions that return a string instead of just a string.
14:54:00  <annevk>bz also proposed that ages ago
14:54:22  <annevk>I think we have something like it for Firefox code internally, at least for platform objects
14:55:27  <bradleymeck>node does as well on util
15:40:44  <devsnek>node just wrap's v8's internal equivalent of this
15:40:51  <devsnek>s/wrap's/wraps
16:06:08  * spion_quit (Ping timeout: 265 seconds)
16:06:53  * spionjoined
16:22:05  * keith_millerjoined
16:43:02  <zkat>it'd be really nice to have a solution to The `instanceof` Problem™. It's still a super painful thing for me on the reg
16:43:23  <zkat>(there's at least one certain library I use constantly that abuses it and ruins my day regularly because of it)
16:48:55  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:52:42  <devsnek>what if we just do Reflect.typeOf and then people can do Reflect.typeOf(x) === Reflect.typeOf(y)
16:52:49  <devsnek>where typeOf is what jasnell proposed
16:53:43  <devsnek>and people can make proxy traps for it cuz everyone loves those
17:00:05  * keith_millerjoined
17:15:50  * cloudshujoined
17:29:09  <devsnek>https://gist.github.com/devsnek/a99cd87a85644224255ef111ef3afebb
17:43:01  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:51:39  * keith_millerjoined
18:03:41  <ljharb>devsnek: the important thing tho is that it’s cross-realm, and, if i save the original copies of the functions, unforgeable - and also, that it is forgeable otherwise.
18:04:27  <devsnek>well ideally the way engines implement it wouldn't be as a node module
18:46:20  * jwaldenjoined
18:58:27  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:46:53  * keith_millerjoined
19:55:37  <bradleymeck>stuff in #node-dev made me wonder if anyone was still interested in taking up value types / I think most people aren't looking at them right now?
20:30:32  <devsnek>do you guys think module authors should be able to detect how their modules get imported (static vs dynamic)
20:31:02  <devsnek>s/guys/folks
20:31:10  <bradleymeck>no
20:31:33  <devsnek>that's the way I'm leaning
20:31:36  <bradleymeck>you can have 2 consumers doing both at the same time anyway so what does that mean?
20:31:50  <devsnek>good point lol
20:43:47  <ljharb>how would you detect that anyways tho
20:44:10  <ljharb>`import * as Module from 'path'; Promise.resolve(Module)` would send the same signal as `import('path')`, no?
21:12:23  <devsnek>jdd suggested using "then" as a way to block people from dynamically importing your module
21:13:03  <bradleymeck>you can get even sneakier, make it only work one time and then remove your then() export
21:15:13  <devsnek>how do you remove your then export
21:15:13  <devsnek>export let?
21:15:51  <bradleymeck>export let then = () => { return ns; then = null; }
21:16:12  <bradleymeck>but that doesn't work reliably in browsers since you can't reliably find a url to import yourself with, you might import another module
21:16:48  <bradleymeck>s/url/specifier/
21:17:17  <devsnek>import(import.meta.url)
21:17:24  <bradleymeck>nope
21:17:36  * devsnekgives up and becomes an obj-c dev
21:17:47  <bradleymeck>https://github.com/nodejs/modules/issues/62#issuecomment-380576688
21:18:19  <bradleymeck>same behavior happens if you use import.meta.url
21:19:31  <devsnek>oh you meant with module map cache
21:20:16  <bradleymeck>yup, you return a new module instance so not the same and that means it has another then()
21:20:38  <devsnek>i thought you meant like (assuming the server isn't doing anything stupid) there was no way for a module to know the url that will result in getting <an instance> of that module
21:20:49  <devsnek>where <an instance> may or may not be an existing cached one
21:21:23  <bradleymeck>don't understand the situation but i can probably cook up ways to return other module source texts for import.meta.url
21:21:41  <devsnek>can't we just all agree to not break things
21:22:38  <bradleymeck>idk if it really is breaking things, just showing that they don't act how they naively look
21:24:53  <devsnek>how i see js: https://xkcd.com/1992/
21:27:18  <bradleymeck>js is well designed given all the crazy constraints it has and being so dynamic
21:28:09  <devsnek>the new stuff is better than the old stuff
21:59:12  <bradleymeck>idk, most of the new stuff builds on and uses helpful ideas of the old stuff.
23:27:39  * keith_millerquit (Quit: Textual IRC Client: www.textualapp.com)
23:40:36  * keith_millerjoined