01:38 | <Jack Works> | oh... I though dev.to is a new blogger for programmers. And how people misunderstand the API also give us information about how to improve it |
04:19 | <devsnek> | dev.to makes me very sad. so much useful content pushed out of the way for incorrect clickbait articles. |
08:07 | <sideshowbarker> | If anybody has a few minutes to do a technical review of https://github.com/mdn/content/pull/13681 that’d be great …as far as whether it’s a useful addition to the docs, and accurate |
08:07 | <sideshowbarker> | comments welcome here or there |
08:19 | <nicolo-ribaudo> | I'd rather just say "the sort implementation can vary among engines, so there is no guarantee about the order array elements are compared or how many times `compareFn` is called" |
08:21 | <nicolo-ribaudo> | I find mentioning the array length to be confusing, since in the general case sort algorithms are expected to be O(n*log(n)) or O(n²) (regardless of what JS engines do) |
08:36 | <sideshowbarker> | nicolo-ribaudo: thanks |
19:26 | <devsnek> | so uh |
19:26 | <devsnek> | https://devblogs.microsoft.com/typescript/a-proposal-for-type-syntax-in-javascript/ |
19:27 | <devsnek> | i will be very sad if we put type syntax in the language and it doesn't have some sort of reflection capability like python |
19:28 | <bakkot> | I would not regard this as "putting type syntax in the language" |
19:28 | <bakkot> | it's just adding a dozen new, weird comment forms |
19:28 | <bakkot> | personally I am inclined to regard the existing comment forms as adequate |
19:29 | <devsnek> | yeah calling them comment forms is what makes me sad |
19:30 | <devsnek> | i mean they don't need to be evaluated, python just gives you strings of them |
19:32 | <bakkot> | I can't say I've ever used python's type reflection |
19:32 | <bakkot> | or, for that kind of types |
19:32 | <devsnek> | it enables some very cool stuff |
19:32 | <bakkot> | what is the thing you use it for? |
19:33 | <devsnek> | for example, @server.route('/foo') fn get_foo(body: T) |
19:33 | <devsnek> | server can automatically validate the body against T |
19:34 | <devsnek> | another example i think is very cool is discord.py, which allows you to specify how discord bot commands are parsed, like def ban_user(user: User) |
19:36 | <shu> | i don't think i'd be supportive of having reflection capabilities here |
19:36 | <shu> | the implementation complexity and runtime costs would be too high -- i can only imagine some kind of reparsing when reflection is actually required, there's no way it'd be acceptable to parse it and actually keep the info around |
19:36 | <devsnek> | i really wish we could combine the usefulness of python with the expressiveness of js |
19:37 | <devsnek> | the implementation complexity and runtime costs would be too high -- i can only imagine some kind of reparsing when reflection is actually required, there's no way it'd be acceptable to parse it and actually keep the info around |
19:40 | <devsnek> | basically exactly like how Error.prototype.stack is a lazy property in v8 |
19:43 | <shu> | i'm not claiming impossibility, just undesirability |
21:05 | <ljharb> | basically exactly like how Error.prototype.stack is a lazy property in v8 |
21:06 | <ljharb> | (but the stacks proposal isn't anywhere near close enough to advancing for that to be a discussion point yet) |
21:06 | <devsnek> | wdym eagerly? |
21:06 | <devsnek> | like generate a stack trace string on new Error() instead of when the .stack property is accessed? |
21:07 | <ljharb> | correct |
21:07 | <devsnek> | i mean it should be invisible to js code |
21:07 | <ljharb> | true, if it can be unobservably optimized then obv the proposal/spec wouldn't care :-) |
21:08 | <devsnek> | i guess its (error instance).stack instead of on the prototype but |
21:09 | <devsnek> | its not a js getter so that should be fine |
21:09 | <devsnek> | its engine magic |
21:10 | <ljharb> | the proposal would make it an internal slot, observable via a normative-optional getter on the prototype (not an own property), and also via a static method or two on Error. so it def could be lazily generated as long as the contents matched "as if" they were eagerly generated |