2019-11-01 [17:13:55.0000] bterlson: I am planning to attend the november TC39 meeting in december along with Chip, may I please get access to the reflector repo? [17:16:23.0000] bterlson: my github is also NilSet , the account is in the Evernote github org. let me know if you need any other kind of authentication [17:18:37.0000] we're gonna need your credit card number and your mother's maiden name [17:20:05.0000] at least i get to keep my dna to myself [17:20:41.0000] for now [17:20:49.0000] why do you think we have in-person meetings 👀 [17:38:34.0000] devsnek: collecting hair samples? 😱 [17:39:09.0000] fingerprints [17:39:26.0000] the tc39 stickers harvest your dna as you apply them to your shiny laptop [17:45:43.0000] saved once more by never putting any decorations on anything [17:46:04.0000] except function declarations [20:06:24.0000] the pad functions remind me of ln -ls [20:06:31.0000] in that i can never remember the arguments of either [05:58:59.0000] Iterator.from() as proposed seems weird to me [05:59:23.0000] what is weird is that we already have GetIterator in the spec, and that's good enough for every place the spec needs to get an iterator from something [05:59:37.0000] seems to me Iterator.from() is fine but it should just be steps 1-5 of GetIterator [05:59:45.0000] (i mean it's fine for it to exist) [06:02:18.0000] i'll file an issue [07:21:36.0000] devsnek: What is the rationale for %WrapForValidIteratorPrototype%? [07:21:50.0000] Looks like it was introduced in https://github.com/tc39/proposal-iterator-helpers/commit/49d13bd528e4488084f885a987153179d9452cf9 but the commit message doesn't say what feedback [07:45:57.0000] filed https://github.com/tc39/proposal-iterator-helpers/issues/61 [12:43:54.0000] ljharb: I suppose I'm not required to keep a `ToString` call after a typecheck, am I? [12:44:53.0000] or maybe I need to cast the string primitive to a `String`? [12:46:34.0000] Okay, wait, this is fun. [12:47:05.0000] In https://github.com/tc39/proposal-temporal/issues/230#issuecomment-548205490 we discussed adding typechecks, but what if the argument is a `String` object? [12:47:36.0000] Do we need to handle that? Should I let it go through and fail to be coerced and throw? [12:51:18.0000] ryzokuken: if you want a string, just use ToString [12:51:35.0000] or you can throw if it's not a string [12:51:40.0000] Yeeeah, I'm using `ToString` right now. [12:51:40.0000] but both is unnecessary [12:52:11.0000] The fun part is, we decided to merge `from` and `fromString`... [12:52:28.0000] and now I have this typecheck for `object`s and `string`s. [12:52:43.0000] But `String`s are `object`s, so it'll throw currently. [12:52:58.0000] idk if that's something people would be okay with? [12:55:28.0000] String as in normal string or String as in instance of %String% [12:55:57.0000] Yes, capital S String as in instance of `%String%`. [12:56:50.0000] it goes through typeof object check, but isn't a valid property bag like it's expected to be, so `from` will throw. [12:57:25.0000] that seems reasonable to me [12:57:54.0000] That's what I'm going with anyway, feel free to block the PR if anyone wants to discuss this behavior though. [13:43:15.0000] ryzokuken: tbh i don't think we have precedent here [13:43:25.0000] ljharb: :/ [13:43:37.0000] What are your opinions? [13:43:42.0000] ryzokuken: iow i think you could make a case for "check for Type String, else Object", or, "is a string or a String object, else Object" [13:43:59.0000] i, of course, have a package you could use for the polyfill if you go with the latter [13:44:16.0000] Idk, throwing on `String` while accepting `string` feels weird. [13:44:21.0000] true [13:44:30.0000] Yeah, I'd personally prefer `String || string` too. [13:44:36.0000] but i think if you want it to be an Object or a string, a String is a big gray area [13:44:49.0000] lol exactly the problem. [13:45:07.0000] the biggest problem I'm having is not that it's a different behavior. [13:45:13.0000] It's that we're straight up throwing. [13:45:51.0000] I'd imagine a lot of people out there in the wild would pass `String`s. A lot. Unlike our test cases which are 100% literals. [13:46:15.0000] i don't imagine that [13:46:22.0000] it's nonzero but i'd guess it's an extreme rarity [13:47:14.0000] What? Are you sure? I think a lot of people will not have the string as a literal but rather get the value from a library or another thing that returns a `String`. [13:47:25.0000] Buuuuuut `Temporal.now()` [13:47:31.0000] i'm not aware of any library or thing that uses primitive objects [13:47:50.0000] it'd be super unergonomic to return a String because typeof would be misleading on it [13:47:51.0000] They use the `String` class, right? [13:47:53.0000] no [13:47:57.0000] Oh [13:48:10.0000] or rather, `Object('foo')` is instanceof String, yes [13:48:24.0000] but `typeof Object('foo') !== 'string'`, so it's generally considered super bad to produce boxed strings [13:48:32.0000] Wait, sorry, anyway, that shouldn't matter much either way though? [13:48:43.0000] you said "get the value from a library or another thing that returns a `String`." [13:48:48.0000] Yeah [13:48:52.0000] My bad. [13:48:53.0000] i'm saying that i think that virtually nothing in the entire ecosystem will produce a boxed string [13:50:20.0000] So... `typeof arg === 'string' || arg instanceof String` it is? [13:50:28.0000] no, `instanceof` is not reliable across realms [13:50:47.0000] you were talking about a shim of yours... [13:50:47.0000] ryzokuken: you'd have to use https://npmjs.com/is-string [13:51:20.0000] ljharb: question is, how would I express this in the spec text? Do we have an abstract op for this? [13:52:26.0000] ryzokuken: i think you can use "is a String exotic object", or [[StringData]] internal slot [13:52:35.0000] ryzokuken: but if you want to throw when it's not a string or String, then you can use `thisStringValue` [13:53:19.0000] I want two conditions: `string || String` and `non-String objects`. [13:53:28.0000] throw a `TypeError` otherwise. [13:53:51.0000] I think that'll be fairly simple in the polyfill given the module. [13:53:56.0000] agreed [13:54:26.0000] hmm - for the spec text, maybe make a "HasStringValue" abstract op, refactor `thisStringValue` to use it, and then use it in Temporal? [13:55:05.0000] ljharb: make "HasStringValue" in ECMA 262? [13:56:59.0000] ryzokuken: as part of temporal [13:57:14.0000] okay, I'll do that. [13:57:36.0000] will ping you if I hit any roadblocks (which I certainly will, I guess). [13:58:14.0000] sgtm [13:58:28.0000] great. have a nice weekend! [13:58:35.0000] you too [13:59:08.0000] I'd try to fix the whole `from` and `fromString` situation over the weekend so we have something nice to look at next week. [13:59:19.0000] hopefully a rather solid-looking public API. 2019-11-03 [13:39:45.0000] re: https://github.com/tc39/proposal-well-formed-stringify/issues/16, I am a little bit surprised how many languages have inconsistent handling of unpaired surrogates in JSON strings [13:39:51.0000] both rust and php, so far [13:39:55.0000] I guess I am not that surprised [14:06:30.0000] unicode is hard 2019-11-04 [08:37:21.0000] didn't someone vie for async constructors at one point? [10:15:15.0000] bradleymeck: it comes up on esdiscuss every once in a while [10:15:23.0000] and someone asked about it here a month ago or so [10:24:04.0000] it seems not totally unreasonable [10:24:23.0000] I have found myself writing `static async init()` pretty often [10:35:46.0000] bakkot: i'd argue that's what you should do though [10:36:12.0000] ehhhh [10:36:20.0000] `new` returns instance, static method for random async logic stuff [10:36:30.0000] i've used libraries where new returns promises [10:36:35.0000] its kind of annoying [10:36:51.0000] `static async init()` sounds A LOT like Java though. [10:37:06.0000] AsyncClassFactory [10:37:09.0000] `public static int main()` [10:37:10.0000] devsnek: the point is that I want it to be an invariant that a.) `new` returns an instance and b.) all instances are fully initialized [10:37:19.0000] but when full initialization requires async logic, I cannot do this [10:37:32.0000] so `new.await foo()` or whatever seems warranted [10:37:41.0000] you can just do `await new foo()` [10:37:55.0000] then `new` does not return an instance [10:37:57.0000] yeah [10:38:02.0000] (also interacts very poorly with inheritance) [10:38:07.0000] right [10:38:26.0000] i feel like we're agreeing [10:38:46.0000] ... maybe? [10:38:59.0000] are you in favor of async constructors, or do you think `static async init()` is better? [10:39:14.0000] async constructors would return promises right? [10:39:34.0000] I mean, technically yes? [10:39:52.0000] but you would invoke them with `new.await`, rather than `await new` [10:40:01.0000] uh [10:40:03.0000] hmm [10:40:19.0000] i'd probably just go with `static async create()` [10:40:30.0000] (or `super.await()`, in an async constructor, I guess.) [10:40:48.0000] yeah I mean that works [10:40:53.0000] but still interacts poorly with inheritance [10:40:55.0000] this seems like the virality issue that tla has [10:40:58.0000] had* [10:41:20.0000] eh [10:41:22.0000] tla was lucky that the visible edges of graphs always happened to be async [10:41:23.0000] async things are async [10:41:37.0000] but 99.9% of constructors in js are not returning promises [10:41:53.0000] of course, because that's bad [10:41:59.0000] they are just returning not-fully-initialized instances [10:42:09.0000] yeah i'm just saying [10:42:18.0000] since constructors don't have asyncness already [10:42:21.0000] we can't add it in [10:42:22.0000] and relying on calling code to `await obj.init()`, or to never explicitly construct an object but instead do `await clazz.init()` [10:42:30.0000] without causing the viral async problem [10:42:35.0000] I don't think that is a problem? [10:42:41.0000] i guess I don't know what you mean by "problem" [10:42:43.0000] i mean `class X extends Y {}` [10:42:44.0000] async functions work fine [10:42:52.0000] you just `super()` [10:42:57.0000] doesn't matter what Y is [10:43:26.0000] async functions kind of have the same problem [10:43:42.0000] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ [10:43:44.0000] are you talking about the "what color are your functions" thing? [10:43:45.0000] heh, yeah [10:43:51.0000] lol [10:44:02.0000] this is just... not really a problem, in my experience? [10:44:05.0000] async things are async [10:44:09.0000] and that's fine [10:44:10.0000] 🤷🏻‍♂️ [10:44:26.0000] yes, if you have an async thing deep in your stack, all calling code needs to also be async [10:44:28.0000] but, like [10:44:32.0000] it _does_ need to be async [10:44:40.0000] fundamentally, not just as a consequence of the syntax [10:44:51.0000] yeah, i'm just not sure adding syntax helps [10:45:11.0000] it helps because it allows inheritance to work for classes which require async code during initialization [10:45:26.0000] currently you basically cannot do that [10:45:43.0000] `return new Promise` works fine here [10:45:50.0000] but it is kind of hilarious [10:46:04.0000] bradleymeck: doesn't work at all with fields though [10:46:23.0000] I guess it kind of does [10:46:23.0000] i don't use fields currently so i guess i haven't been hit hard by that [10:46:41.0000] mfw fields [10:46:50.0000] `return new Promise(async resolve => { this.foo = await foo(); return this; })` [10:46:53.0000] not just fields though [10:47:03.0000] i know ive used sentinel values as guards for things when i want things only constructed my specific way (such as banning direct `new`) [10:47:44.0000] the argument to new Promise isn't async btw [10:47:47.0000] but these are all just goofy ways of trying to not allow people to construct things async, and people needing to do exactly that [10:48:04.0000] devsnek: its fine if you give it one for `await` to be usable [10:48:13.0000] devsnek: it does not matter [10:48:15.0000] i just mean, you end up with an unhandled rejection [10:48:18.0000] potentially [10:48:34.0000] yeah but whatever, handle your exceptions [10:48:40.0000] devsnek: how so? the return value is the promise [10:48:46.0000] so you still get a way to handle it [10:48:56.0000] bradleymeck: if the async function rejects nothing handles it [10:48:59.0000] oh, i see [10:49:14.0000] yea, `return Promise.resolve().then(async ...` then [10:49:27.0000] but this all just points to how terrible this is without helping the programmer [10:49:42.0000] yea [10:49:51.0000] why is there this restriction if you can do it anyway (poorly) when needed [10:49:58.0000] just add the `async` [10:54:28.0000] i like the restriction because it dissuades people from making async constructors [10:54:53.0000] have you ever used the mozilla source-map lib [10:59:04.0000] yes [10:59:45.0000] why dissuade though? what are you getting out of it? [10:59:49.0000] the class still is unusable sync [11:00:27.0000] i just don't understand how this benefits either side when a class does have async initialization [11:00:59.0000] yeah, curent patterns seem strictly worse [11:01:08.0000] returning a Promise rather than an instance is bad [11:01:15.0000] returning something which is not fully initialized is also bad [11:01:36.0000] i don't really think `new.await` is much better than `static async create() {}` [11:01:49.0000] that's just my opinion though :) [11:02:17.0000] why does it need a new keyword? [11:03:00.0000] bradleymeck: the main reason to want a new keyword is so that it can be used by subclasses invoking `super()` [11:03:14.0000] (though in that case it would be `super.await()`, not `new.await`) [11:03:36.0000] super.await is a super expression though [11:03:40.0000] if you have an async ctor would it ever not await super? [11:03:53.0000] syntax aside, I don't think this makes it any better [11:03:53.0000] devsnek: or whatever; ignore the particular syntax [11:03:59.0000] it's just an awkward situation [11:04:23.0000] devsnek: how is "the class can put all its initialization code in the constructor, so that the constructor never returns half-initialized instances" not better? [11:04:40.0000] I feel like "the constructor should not return instances which are not completely intialized" is a fairly bedrock principle [11:04:51.0000] you can make the constructor fail [11:05:03.0000] unless a certain symbol or something is passed [11:05:23.0000] "use X.create not new X" [11:05:45.0000] sure, yes; that seems... really a very awkward thing to be the officially blessed pattern for this common operation? [11:06:08.0000] hmm I haven't seen it that often [11:06:39.0000] of course there's also a third option [11:06:44.0000] sync constructor, async methods [11:06:45.0000] devsnek: how is requiring programmers to write more boilerplate helping? [11:07:06.0000] boilerplate has a cost of potentially being done wrong [11:07:16.0000] and these solutions do not seem simple [11:07:18.0000] bradleymeck: I don't think people should write them in the first place [11:07:33.0000] devsnek: think/should, people do and APIs are async [11:07:35.0000] sync constructor with async methods is actually really simple [11:07:56.0000] devsnek: how so, you have to track initialization manually? [11:08:23.0000] and then const resource = await this.#resource in methods [11:08:52.0000] hmm I think one of my messages didn't send [11:10:49.0000] that seems like more boilerplate arguments [11:11:07.0000] i don't see how forcing people to do that helps them [11:11:12.0000] you just don't want the alternative? [11:11:58.0000] i'm more concerned about who consumes the api [11:12:10.0000] what about them? [11:12:21.0000] i'd rather use something like `X.create()` [11:12:27.0000] actually i think the web does that too [11:12:47.0000] why [11:12:51.0000] like `navigator.getUserMedia()` instead of `new navigator.VideoFeed()` [11:12:57.0000] ok... but why [11:13:00.0000] wdym [11:13:09.0000] what invariant are you trying to prevent people from breaking [11:13:20.0000] what bugs are caused by using `new` [11:13:28.0000] i don't understand [11:13:41.0000] i just don't think its the appropriate operation [11:13:48.0000] how so? [11:13:54.0000] what is appropriate? [11:14:05.0000] cause new Promise certainly uses new [11:14:09.0000] as do subclasses of it [11:14:20.0000] and you get a promise out of it [11:14:33.0000] a promise to *something* [11:14:39.0000] right [11:14:45.0000] so how is that different? [11:14:46.0000] you could do `async constructor` [11:14:52.0000] devsnek: you don't think `new` is the appropriate operation for... getting a new instance of a class? [11:14:54.0000] and get the same pattern [11:14:57.0000] that seems like probably not the claim you meant [11:15:00.0000] i just dislike such a pattern [11:15:02.0000] but I don't know what claim you meant, if not that [11:15:04.0000] on a subjective level [11:15:21.0000] i just don't see what is dislikable [11:15:37.0000] you call a constructor, which totally doesn't guarantee you get an instance anyway [11:18:22.0000] i'm saying this the same way i would say my favourite colour is purple [11:18:30.0000] its just what i prefer [11:18:31.0000] and no once can like blue? [11:18:35.0000] no one* [11:18:42.0000] no go ahead and like blue [11:18:49.0000] but you dislike blue [11:18:55.0000] and so they shouldn't be using blue [11:18:57.0000] i'm not objecting to you liking blue [11:19:06.0000] you are objecting to me using blue because you want purple [11:19:10.0000] i was just saying my opinion [11:19:36.0000] and your opinion differs from wanting to prevent people from using blue? [11:20:40.0000] i was saying the web pattern seems okay to me [11:20:54.0000] and i wasn't sure there was a huge motivation to need something else [11:21:15.0000] it was more than saying that one pattern seems ok [11:21:24.0000] it was stating that another was not ok [11:21:37.0000] or at least dislikable [11:22:17.0000] even if one pattern is ok, that shouldn't preclude other patterns from being usable [11:22:18.0000] i was just saying i was surprised people want more of that pattern [11:24:21.0000] like that esdiscuss topic about giving js significant whitespace instead of braces [11:25:18.0000] subjectively not a fan, and if enough people are subjectively not fans of it, it won't happen [11:34:03.0000] not really true, i am not a fan of a variety of things that does not mean i attempt to block them [11:34:47.0000] i'm not trying to block anything lol [11:35:28.0000] i'm stating that all but 1 could not be fans of something but if that 1 champion pushes it even with that it would still go through unless someone does block it [11:35:49.0000] i'm just trying to suggest alternatives that don't require modifying the language, which is usually where stuff starts out [11:35:50.0000] not liking some proposal doesn't prevent things from landing [11:36:29.0000] we have the alternatives already though and they are troublesome, the reasons by which we are being told to pursue those troubles is unclear [11:36:45.0000] modifying the language is what tc39 is discussing all the time [12:01:26.0000] devsnek: I still don't understand what exactly it is that you dislike [12:01:55.0000] i just don't get the pattern [12:02:10.0000] like in node we create a handle synchronously and emit an error event [12:02:17.0000] the web has functions that return promises [12:02:30.0000] you don't get having async initialization code? [12:02:36.0000] or... some other pattern? [12:02:42.0000] i don't understand why async constructors are better than doing those things [12:03:36.0000] i get that performing work asynchronously is needed obviously [12:03:39.0000] I don't know what the first things refers to; you generally can't do things synchronously [12:03:44.0000] the functions-returning-promises thing isn't really used with classes, afaict [12:04:32.0000] it works fine if you are just not using classes at all, of course [12:04:46.0000] i don't write that many libraries, but node and the web do this thing where they have some X class with a constructor that always throws, then a `createX` function that creates an instance [12:05:24.0000] but to make it work with a class, you have to do awkward things like forbidding `new`, which is boilerplate you really do not want to require everyone to add, and also a.) does not work with inheritance and b.) requires splitting your initialization code across the constructor and some other async function [12:06:06.0000] is your position that everyone who wants to use classes and has async code should just have that boilerplate to forbid `new`, not use inheritance, and split their intialization code across the constructor and some other async function? [12:06:25.0000] the constructor doesn't generally do anything [12:06:40.0000] but what i mean is people don't usually want to subclass them anyway [12:06:46.0000] because dealing with that in an async way sucks [12:06:57.0000] ... right, the proposal would be to make it not suck [12:07:05.0000] i think it would still suck [12:07:07.0000] just in a different way [12:07:30.0000] though I think people mainly do not subclass because node classes and web classes aren't really intended to be subclassed, with some rare exceptions [12:08:07.0000] in what way would it still suck? [12:08:20.0000] like if i wanted to create my own class that provided the functionality [12:08:20.0000] just that you have to make any class which extends an async class also async? [12:08:23.0000] that does not seem so bad. [12:08:29.0000] i'd probably wrap it so that it was a sync constructor with async methods [12:08:35.0000] since that's a nicer api to use [12:08:40.0000] i wouldn't subclass it [12:09:00.0000] I don't think that's actually a nicer API, if the methods are sync once initialization has completed? [12:09:09.0000] like, let's say my class is a wrapper for values returned by some API [12:09:10.0000] they aren't [12:09:15.0000] ... why not [12:09:25.0000] wait, what do you mean by "why not" [12:09:29.0000] er [12:09:33.0000] what do you mean by "they aren't" [12:09:45.0000] `async doThing() { const x = await this.#x; }` [12:09:54.0000] it doesn't become sync once `this.#x` fulfills [12:09:57.0000] right, of course you can write that [12:10:17.0000] my point is, you can also have a situation where there is one async operation in the lifetime of the class, which occurs during initialization [12:10:24.0000] and every method invocation after that point can be synchronous [12:10:42.0000] making them have to be async at that point seems like a strictly worse API to use [12:11:08.0000] just having worked with both patterns [12:11:16.0000] i prefer the async method one [12:11:27.0000] source-map uses the async constructor pattern if you want to try it out [12:11:34.0000] I think you are literally the only person I have ever heard express that preference [12:11:54.0000] every one else I have ever talked to prefers things to be sync when they can be sync [12:12:16.0000] "when they can be sync" is pretty abstract [12:12:28.0000] if they aren't exposed synchronously you'd never know [12:12:52.0000] of course sometimes you do not know when an API is more awkward than it needs to be because you do not know about the library interals [12:13:10.0000] but it still seems like, as the library author, given the choice of making your API less awkward, you should do so [12:13:18.0000] sync methods are generally less awkward than async methods [12:13:23.0000] i rewrote the source-map library to not use async constructors [12:13:33.0000] which in my mind was making the api less awkward [12:13:39.0000] i guess to you that makes it more awkward [12:14:05.0000] I agree that the current patterns for async constructors themselves are not great, but again, the point of this would be to make those better [12:14:22.0000] after that point - once the class has been constructed - you agree that sync methods are easier to use, yes? [12:14:32.0000] sure [12:14:33.0000] well [12:14:36.0000] maybe [12:14:40.0000] i don't mind writing `.then` and `await` [12:14:53.0000] sure, but it easier all around if you don't have to [12:14:58.0000] i'm just saying, as a consumer, there isn't a huge difference between `await new x` and `new.await x` [12:15:07.0000] i understand not using new Promise in your constructor is nice [12:15:19.0000] there is a huge difference when inheritance is involved [12:15:50.0000] sometimes the way a class is consumed is by subclassing it [12:15:50.0000] actually, do you have examples of things where this would help with inheritence? [12:15:53.0000] i'm curious [12:16:40.0000] specifically, the case is that your superclass needs to do some async initialization, and your constructor code needs to wait for the superclass instance to be fully initialized before it can do its thing [12:16:50.0000] yeah i get the idea [12:16:57.0000] i've just never really encountered this problem [12:17:09.0000] like normally things acquired asynchronously represent data, not functionality, so people don't tend to subclass them, they tend to wrap them [12:17:15.0000] at least in my experience [12:17:48.0000] classes marry data and functionality; that's kind of the point [12:17:48.0000] or the subclass is separate from the async part [12:18:06.0000] like in discord.js, the thing that creates a message instance is not `new Message` [12:18:22.0000] its receiving a message over a channel of data, so subclassing the message instance doesn't break anything [12:18:28.0000] it still gets created synchronously [12:18:57.0000] subclassing the message class* [12:20:37.0000] bakkot: i'm saying, classes aren't usually responsible for acquiring the data [12:21:07.0000] classes are often responsible for transforming the data into a suitable internal representation, though, and that is sometimes not a sync operation [12:21:18.0000] coming up with a way to do inheritance for an abstraction where initialization is async takes a bit of finesse and creativity perhaps, but I think an "async constructor" cure would be worse than the disease - it will tend to muddy the waters between memory allocation/initialization and event-loop programming. [12:22:20.0000] zenparsing: yeah, I don't know that `async constructor` is necessarily the right solution; haven't thought about it much. mostly just gesturing at the existence of the problem. [12:22:28.0000] though, say more about "muddy the waters between memory allocation/initialization and event-loop programming"? [12:23:37.0000] specifically, it is not obvious how async constructors do that any more than any other class would; possibly I do not know what you are referring to [12:23:56.0000] node file handles as an example, could use this in theory [12:24:02.0000] but I'm not sure there would be a point [12:24:11.0000] consumers wrap them, they wouldn't want to subclass them [12:24:45.0000] I've just never had a time I wanted to do this, so I'm curious about specific examples [12:25:57.0000] source-map should arguably return a promise to the complete library with sync constructors with sync methods on them [12:26:36.0000] its only async because of loading wasm [12:28:04.0000] devsnek: riffing off that, one could imagine a class which, internally, dynamically generates and loads some wasm, and exposes a sync interface to the underlying wasm [12:28:27.0000] consumers would not need to know wasm was involved at all [12:29:05.0000] and subclasses could build new methods on top of the existing ones, or overload them to provide more checks than the base class does, or whatever [12:29:08.0000] i mean thats kind of what it does now [12:29:17.0000] it returns a promise from the constructor [12:30:23.0000] it's also the only lib I know of that does that [12:35:44.0000] I guess you can subclass it by doing `return super().then(...)` [12:43:17.0000] yeah [12:43:59.0000] not really natural though [12:48:56.0000] bakkot: but you're suggesting kind of the same pattern, just with await, right? [12:49:16.0000] like a sync function using .then vs an async function using await [12:50:39.0000] yeah [12:50:45.0000] with roughly the same advantages and disadvantages 2019-11-05 [21:11:15.0000] does anyone know anyone who is really good with babel transforms [21:11:22.0000] or is anyone really good with babel transforms [21:12:00.0000] i need to recursively expand call arguments to separate variables [09:07:35.0000] devsnek: can you expand on that [09:08:03.0000] you mean move call arguments ala `foo(x,y)` to `let _0 = x, _1 = y; foo(_0, _1);` ? [09:08:16.0000] nice pun [09:08:22.0000] and yeah [09:08:25.0000] i figured it out though [09:08:39.0000] https://github.com/engine262/engine262/blob/master/transform.js#L124 2019-11-06 [19:58:08.0000] devsnek: does engine262 do Annex B? [19:58:14.0000] jmdyck: no [19:58:22.0000] well it uses acorn so it does annex b syntax [19:58:32.0000] but i haven't implemented any annex b runtime semantics [19:59:34.0000] ok, that fits then. I found a mistake in one of my eliminate-lex-env commits, but it's in one of the Annex B insertions [19:59:41.0000] heh [19:59:53.0000]