00:33:22
| * jwalden | quit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]) |
00:48:48
| * bradleymeck | joined |
01:43:10
| * darkSeid_ | quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
02:10:48
| * marxo_ | quit (Ping timeout: 272 seconds) |
02:32:40
| * mylesborins | quit (*.net *.split) |
02:32:40
| * ChanServ | quit (*.net *.split) |
02:33:58
| * howdoi | quit (Quit: Connection closed for inactivity) |
02:34:39
| * ChanServ | joined |
02:36:17
| * mylesborins | joined |
02:39:13
| * gibson042 | joined |
03:03:48
| * gibson042 | quit (Read error: Connection reset by peer) |
03:06:37
| * gibson042 | joined |
03:23:00
| * gibson042 | quit (Ping timeout: 272 seconds) |
04:13:39
| * bradleymeck | quit (Quit: bradleymeck) |
04:38:29
| * not-an-aardvark | joined |
04:40:32
| * jmdyck | quit (Remote host closed the connection) |
05:28:30
| * caridy | joined |
05:29:41
| * caridy__ | quit (Read error: Connection reset by peer) |
05:38:51
| * caridy | quit (Remote host closed the connection) |
05:42:21
| * Emulous | joined |
05:47:01
| <Emulous> | Has any thought been given to some pleasant syntactic sugar like `Object.typeOf()` to get `null` returning "null" (and, perhaps depending on a second argument of options, `Array` instances returning "array" and/or constructors/class instances returning their class name)--with behavior otherwise like "typeof"? |
06:01:33
| * Emulous | quit (Ping timeout: 264 seconds) |
06:03:25
| * howdoi | joined |
06:07:23
| * caridy | joined |
06:07:27
| * caridy | quit (Remote host closed the connection) |
06:07:35
| * caridy | joined |
06:07:44
| * caridy | quit (Remote host closed the connection) |
06:16:05
| * Draggor | quit (Ping timeout: 240 seconds) |
06:18:09
| * Draggor | joined |
06:57:58
| * not-an-aardvark | quit (Quit: Connection closed for inactivity) |
07:08:06
| * caridy | joined |
07:12:09
| * caridy | quit (Ping timeout: 240 seconds) |
07:30:42
| * Havvy | joined |
07:34:37
| * darkSeid_ | joined |
07:54:21
| * darkSeid_ | quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
08:30:20
| * Emulous | joined |
08:47:16
| * Emulous | quit (Ping timeout: 272 seconds) |
09:05:45
| * Emulous | joined |
09:10:25
| * caridy | joined |
09:14:27
| * caridy | quit (Ping timeout: 240 seconds) |
09:58:22
| * marxo | joined |
11:07:04
| * marxo_ | joined |
11:11:01
| * marxo | quit (Ping timeout: 260 seconds) |
11:12:01
| * caridy | joined |
11:14:39
| * marxo_ | quit (Ping timeout: 248 seconds) |
11:16:21
| * caridy | quit (Ping timeout: 256 seconds) |
11:25:07
| * mylesborins | quit (Quit: farewell for now) |
11:25:38
| * mylesborins | joined |
12:46:12
| * jmdyck | joined |
13:02:29
| * bradleymeck | joined |
13:15:01
| * bradleymeck | quit (Quit: bradleymeck) |
13:23:42
| * marxo | joined |
13:48:44
| * Emulous | quit (Ping timeout: 272 seconds) |
13:58:35
| * marxo_ | joined |
14:01:52
| * marxo | quit (Ping timeout: 268 seconds) |
14:10:27
| * gibson042 | joined |
14:12:20
| * bradleymeck | joined |
14:38:57
| * spectranaut | quit (Quit: No Ping reply in 180 seconds.) |
14:39:40
| * caridy | joined |
14:40:04
| * spectranaut | joined |
14:44:17
| * caridy | quit (Ping timeout: 248 seconds) |
15:06:47
| * Emulous | joined |
15:56:16
| * Emulous | quit (Ping timeout: 260 seconds) |
16:16:35
| * AtumT | joined |
16:35:55
| * jwalden | joined |
16:42:51
| * bradleymeck | quit (Quit: bradleymeck) |
16:47:10
| * caridy | joined |
16:47:40
| * caridy | quit (Remote host closed the connection) |
16:48:12
| * caridy | joined |
17:41:20
| * marxo_ | quit (Ping timeout: 248 seconds) |
17:53:44
| * bradleymeck | joined |
18:26:28
| * caridy | quit (Ping timeout: 240 seconds) |
18:27:51
| * caridy | joined |
18:28:32
| * jwalden | quit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]) |
19:05:57
| * darkSeid_ | joined |
19:06:04
| * AtumT | quit (Read error: Connection reset by peer) |
19:07:25
| * AtumT | joined |
19:19:11
| * AtumT_ | joined |
19:19:45
| * AtumT | quit (Read error: Connection reset by peer) |
19:50:24
| * caridy | quit (Ping timeout: 248 seconds) |
19:52:55
| <Domenic> | I'm thinking of preparing a proposal to censor Function.prototype.toString in a per-function opt-in manner. Do people have any ideas on the API? So far I have (a) a new pragma e.g. 'use no Function.prototype.toString'; and (b) a symbol e.g. fn[Symbol.noFunctionToString] = true |
19:53:21
| <Domenic> | aklein: ^ |
19:53:41
| <bradleymeck> | please no on the symbol |
19:54:04
| <bradleymeck> | is there ever a time that a function wants to go from censored to public? |
19:54:20
| <annevk> | What's the motivation for this? So you can do what the platform does? |
19:54:51
| <Domenic> | That, and memory usage, and encapsulation |
19:55:16
| <Domenic> | bradleymeck: I wasn't envisioning enabling un-censoring; fair point. |
19:57:15
| <aklein> | Domenic: uncensoring shouldn't be supported if we want to allow memory optimization. I have to admit I was imagining something outside the language, a la CSP |
19:57:35
| <Domenic> | Hmmm interesting |
19:57:47
| <Domenic> | I guess the question is scope; CSP would be whole page scoped |
19:59:41
| * not-an-aardvark | joined |
20:00:16
| <aklein> | For engines I think it might be useful to know per resource, which I guess is more fine-grained...and I guess a downside of CSP-like is that you also get the CSP-y problem of libraries needing to deal with being loaded into such an environment |
20:00:51
| <aklein> | if you want per-function the pragma seems like the right place to start, as ugly as it is |
20:05:57
| * jwalden | joined |
20:06:09
| <ljharb> | Domenic: if a pragma, why not a keyword? |
20:06:19
| <ljharb> | Domenic: `secret function () {}` or something |
20:06:22
| <Domenic> | ljharb: backward compat |
20:06:30
| <ljharb> | ah, true |
20:06:46
| <Domenic> | Also you could then do it per source file |
20:06:49
| <ljharb> | seems like there'd be pushback on more pragmas, but maybe it's fine for this case |
20:13:54
| <Domenic> | yeah, i'm unsure. |
20:19:49
| <ljharb> | would that impact stack traces (line numbers specifically), or be unrelated? |
20:21:19
| <cloudshu> | Domenic: i am in favor of such censorship |
20:22:28
| <cloudshu> | also agreed on that censorship will be a 1-way switch |
20:22:32
| <cloudshu> | or, should be |
20:23:24
| <cloudshu> | i'm having trouble imagining where this censorship is desired on a per-function granularity though |
20:23:41
| <ljharb> | it definitely feels like it needs to be tied to the source text, just like the toString output is, and not runtime-changeable in either direction |
20:23:57
| <Domenic> | Yeah, I think I'm abandoning the symbol idea; good thing I asked this channel |
20:24:11
| <Domenic> | I think this would impact line numbers in the same way that C++ functions currently do. (I'm not sure what that is.) |
20:24:38
| <ljharb> | whatever the impact, it'd need to integrate with the stacks proposal (if not the current one, the followon ones mark wants to do) |
20:24:42
| <Domenic> | cloudshu: I agree per-function might not be useful. Per source file is useful though, as opposed to whole-web-page. |
20:24:49
| <Domenic> | ljharb: agreed. |
20:24:59
| <ljharb> | and you want it to work on Scripts too, not just Modules? |
20:25:19
| <cloudshu> | Domenic: yeah, agreed |
20:25:42
| <ljharb> | also would i be able to runtime-distinguish native functions, from non-native censored functions? |
20:25:59
| <cloudshu> | ljharb: wait, why would line numbers be impacted by discarding source? |
20:26:15
| <ljharb> | cloudshu: if the source text is censored, and a stack trace still points to a line number within it, that might be an issue |
20:26:32
| <cloudshu> | ljharb: i'm not understanding in what way |
20:26:43
| <ljharb> | off the top of my head i'm not sure either |
20:26:57
| <ljharb> | i've only had 20 minutes to think about toString censorship :-p |
20:27:00
| <ljharb> | i'm just anticipating an interaction |
20:27:01
| <cloudshu> | ljharb: "censorship" here is just that toString() returns some fixed string "[no source]" or whatever, right? |
20:27:08
| <cloudshu> | not any additional censorship |
20:27:45
| <ljharb> | i assume so. but toString serves as a quasi-toSource atm, so despite the committee's preference to avoid toSource, there still might be interesting interactions to consider |
20:27:50
| <ljharb> | source maps, for example |
20:28:04
| <ljharb> | the debugger having superpowers to see into censored source |
20:28:27
| <cloudshu> | debuggers most definitely do not use toString to do source mapping |
20:28:30
| <ljharb> | well yeah |
20:28:48
| <ljharb> | but would it be surprising or desirable for a dev using a debugger to be able to see censored function source |
20:28:52
| <cloudshu> | i am skeptical on line numbers being an issue -- toString for a long time in SM didn't even return the original string |
20:28:58
| <ljharb> | it very well might be the case that everything i've mentioned as a possible pitfall is a non-issue. i'm just spitballing :-) |
20:29:26
| <cloudshu> | ljharb: maybe it's because "censorship" has very wide connotation |
20:30:09
| <Domenic> | ljharb: I don't think we'd want to have them be distinguishable? But you get the benefits even if they are, so if there's some reason, then we could do it. |
20:30:57
| <ljharb> | Domenic: lodash for example has a lot of pivots on "is this function native or not", for better or worse |
20:33:17
| <cloudshu> | Domenic: well, they're necessarily distinguishable if they return a fixed string in actual impls |
20:33:29
| <cloudshu> | if their toString, that is |
20:33:38
| <Domenic> | ljharb: sure, the question is, do we want lodash to detect these censored things as native or not. |
20:34:08
| <Domenic> | cloudshu: if this version makes it return `function foo() { [native code] }` then they're not |
20:34:18
| <cloudshu> | Domenic: ah ha, i see |
20:34:44
| <cloudshu> | i have vague misgivings about giving users ability to masquerade their functions as native code |
20:35:20
| <cloudshu> | wait, they can easily enough do this now, i guess |
20:38:39
| <ljharb> | cloudshu: no they can't |
20:39:12
| <ljharb> | cloudshu: `Function.prototype.toString.call()` with a cached/known-good Function.prototype.toString will only ever return the native code thing for real native functions |
20:41:34
| * caridy | joined |
20:55:38
| <cloudshu> | ljharb: ah ok, are most frameworks doing that? |
20:56:11
| <cloudshu> | in any case, then my misgivings stand |
21:04:48
| * caridy | quit (Ping timeout: 240 seconds) |
21:07:35
| <Bakkot> | It is already possible to do per-function hiding of .toString by overwriting F.p.toString, but it's somewhat tricky to do well since you also have to overwrite it in new realms |
21:08:06
| <Bakkot> | (if you run first of course) |
21:09:03
| <Bakkot> | anyone who is serious about detecting nativeness is using a cached F.p.toString, though, yes |
21:12:57
| <Bakkot> | Domenic: a possible API would be a method on Function.prototype like .bind |
21:13:15
| <Domenic> | Ah, not bad. |
21:13:39
| <Bakkot> | (.bind already accomplishes this, in fact, but with other effects you probably don't want.) |
21:14:58
| <Bakkot> | '.sourceless()', maybe? |
21:15:23
| <cloudshu> | .noString() |
21:17:47
| <Bakkot> | I guess there's two possibilities for how such a method could work - changing the behavior of F.p.toString for its receiver, or giving you a new function with the same behavior except for F.p.toString. |
21:17:50
| <Bakkot> | would strongly prefer the latter. |
21:18:16
| <Domenic> | Hmm, but all those problems with homeobject copying etc... |
21:18:23
| <Bakkot> | would require more work from enginges to get the memory usage benefits, but I think it would be a lot nicer. |
21:20:10
| <cloudshu> | and identity issues |
21:20:39
| <Bakkot> | I would expect the common pattern to be (function literal).sourceless(), in which case it really wouldn't matter. |
21:26:15
| <Domenic> | How do you do that for methods though |
21:26:18
| <Domenic> | And classes |
21:26:26
| <Domenic> | Leaning back toward directive. |
21:26:30
| <Bakkot> | Mm, fair, hadn't considered those. |
21:26:44
| <Bakkot> | Works fine for classes, but not so much for methods. |
21:29:06
| <cloudshu> | Reflect.sourceless(thing)? |
21:29:28
| <cloudshu> | i still want noString though |
21:30:48
| * darkSeid_ | quit (Quit: Textual IRC Client: www.textualapp.com) |
21:31:16
| <Bakkot> | I increasingly just want to start all my programs with `delete Function.prototype.toString;` |
21:32:29
| * darkSeid_ | joined |
21:40:28
| <ljharb> | could you do it on methods with a decorator? |
21:40:44
| <ljharb> | ie, `.sourceless()` or whatever for the normal case, and a decorator just does that replacement for you |
21:40:54
| <ljharb> | (such that `f !== f.sourceless()`, just like .bind) |
21:41:37
| <Bakkot> | decorators for methods in object literals aren't even a proposal at the moment, IIRC |
21:42:16
| <ljharb> | sure, but absent a way to observe [[HomeObject]], are methods in object literals anything more than concise syntax at the moment? :-) |
21:42:36
| <ljharb> | you're right tho that either way we'd want a decorator to work for that :-/ |
21:43:47
| <Bakkot> | I do think a new prototype method would have a much higher chance of making it through committee |
21:43:50
| <Bakkot> | syntax is expensive |
21:44:53
| <ljharb> | prototype methods aren't syntax |
21:44:57
| <ljharb> | but sure, `Reflect.sourceless()` or similar is fine |
21:45:11
| <ljharb> | (altho we'd need a different namespace, since Reflect is just for proxy traps iirc) |
22:06:21
| <Domenic> | I'm glad that me saying that over and over (about Reflect) seems to have finally stuck :) |
22:06:48
| <Domenic> | Bakkot: do you think directives are as expensive as syntax? |
22:07:12
| <Bakkot> | ljharb: right, that's my point |
22:07:16
| <Bakkot> | Domenic: uhhh approximately yes. |
22:07:20
| <Bakkot> | they are syntax. |
22:07:51
| <Bakkot> | Not as much as, say, `match`, but still way more than a new prototype method. |
22:08:14
| <ljharb> | Domenic: lol what should the different namespace be called tho? some have suggested "System" ᕕ( ᐛ )ᕗ |
22:08:39
| <ljharb> | (inb4 response: just put it on Function) |
22:13:15
| * caridy | joined |
22:13:32
| * caridy | quit (Remote host closed the connection) |
22:14:08
| * caridy | joined |
22:17:40
| * ChanServ | quit (*.net *.split) |
22:22:35
| <aklein> | does anyone of know a previous attempt to introduce async JSON parsing/serialization (the latter is a bit trickier, I know)? I see plenty of chatter about the lack of it on the interwebs, but nothing TC39/es-discuss related |
22:23:04
| <ljharb> | aklein: i'm pretty sure it's been on esdiscuss, one sec |
22:23:31
| <aklein> | ljharb: ah, so there is, didn't poke specifically enough there |
22:23:50
| <ljharb> | https://esdiscuss.org/topic/please-help-with-writing-spec-for-async-json-apis |
22:24:22
| * ChanServ | joined |
22:25:43
| * Emulous | joined |
22:25:52
| <aklein> | ljharb: thanks! reading through that thread now...doesn't sound like this may have ever gotten behind es-discuss though |
22:26:06
| <ljharb> | behind? |
22:27:03
| <ljharb> | i think it died there tho; seems like it's worth a stage 0 at least |
22:27:03
| <aklein> | *beyond |
22:28:57
| * ChanServ | quit (*.net *.split) |
22:31:45
| * ChanServ | joined |
22:31:59
| * Emulous | quit (Ping timeout: 248 seconds) |
22:32:14
| * Emulous | joined |
22:45:51
| * Emulous | quit (Ping timeout: 248 seconds) |
22:50:01
| * caridy_ | joined |
22:50:08
| * caridy | quit (Ping timeout: 240 seconds) |
23:03:33
| * jwalden | quit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]) |
23:43:50
| * Emulous | joined |
23:52:30
| * caridy_ | quit (Remote host closed the connection) |
23:55:57
| <Emulous> | Has any thought been given to some pleasant syntactic sugar like `Object.typeOf()` to get `null` returning "null" (and, perhaps depending on a second argument of options, `Array` instances returning "array" and/or constructors/class instances returning their class name)--with behavior otherwise like "typeof"? |
23:56:50
| <bradleymeck> | Emulous: why does it need to be syntax? |
23:57:20
| <bradleymeck> | do you just mean an API? |
23:57:35
| <Emulous> | ah yes, sorry, just an API |
23:57:48
| <Emulous> | lexical sugar :) |
23:59:03
| <bradleymeck> | it has been looked at many times, I just haven't seen it make much progress. Symbol.toStringTag kind of does what you want |
23:59:36
| <bradleymeck> | that + Object.prototype.toString.call(value) |