| 00:33:05
| * not-an-aardvark | joined |
| 00:33:39
| * Fishrock123 | quit (Remote host closed the connection) |
| 00:39:59
| * Fishrock123 | joined |
| 00:40:00
| * Fishrock123 | quit (Remote host closed the connection) |
| 01:01:38
| * Fishrock123 | joined |
| 01:01:41
| * Fishrock123 | quit (Remote host closed the connection) |
| 01:24:45
| * jwalden | quit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]) |
| 01:37:02
| <TimothyGu> | ljharb: you here? |
| 01:38:48
| <ljharb> | yo |
| 01:39:36
| <TimothyGu> | ljharb: did you see https://github.com/tc39/ecma262/issues/1067#issuecomment-358158948 |
| 01:41:06
| <ljharb> | yes |
| 01:41:52
| <ljharb> | i'm not sure allen's concerns are warranted; nothing in the spec mandates that "internal slots" even exist at all |
| 01:42:09
| <TimothyGu> | Okay so it's not just me |
| 01:43:12
| * Fishrock123 | joined |
| 01:43:21
| * Fishrock123 | quit (Remote host closed the connection) |
| 01:43:57
| <TimothyGu> | There's then the question of this set of own properties exists for all objects, or only ordinary objects |
| 01:44:23
| <TimothyGu> | If it only does for ordinary objects then things like Array exotic objects will break badly |
| 01:44:36
| <ljharb> | the point of the refactor would be "all objects" |
| 01:44:45
| <ljharb> | otherwise it doesn't simplify anything |
| 01:45:23
| <TimothyGu> | well I think ordinary object-only that's what Allen is claiming the current definition for own properties applies to |
| 01:46:08
| <TimothyGu> | from what I understand anyway |
| 01:52:45
| <ljharb> | sure, but we'd want to define it for builtin exotics too |
| 01:52:54
| <ljharb> | (theoretically) |
| 01:54:17
| <TimothyGu> | except for Proxy I guess |
| 01:56:28
| <ljharb> | sure, it'd be the default methods that look at the [[Properties]] slot, an Proxy doesn't have default methods |
| 01:56:33
| <ljharb> | or rather has special ones |
| 01:56:38
| <TimothyGu> | right |
| 01:57:09
| <TimothyGu> | so what do you think about specifying a [[Properties]] slot for ordinary objects, and then *explicitly* saying which of the standard exotics have [[Properties]] as well? |
| 01:57:23
| <TimothyGu> | instead of the current handwavy description |
| 01:58:19
| <ljharb> | that sounds like what i'd expected from the beginning |
| 01:58:46
| <ljharb> | allen's concerns might prove true tho if using that slot complicates a bunch of other places |
| 01:58:53
| <ljharb> | like EnumerateOwnProperties, for..in, etc |
| 01:59:53
| <TimothyGu> | yeah |
| 02:00:02
| <TimothyGu> | that's why I explicitly avoided using a List for [[Properties]] |
| 02:04:41
| <jmdyck> | TimothyGu: re that issue, I'm not clear on what you're saying is unintuitive/confusing/unfortunate about HasOwnProperty -> [[GetOwnProperty]] -> OrdinaryGetOwnProperty -> asks if object O has an own property with key P. |
| 02:04:49
| <jmdyck> | (e.g.) |
| 02:05:41
| <Domenic> | The last step is undefined, is the confusing part |
| 02:06:20
| <Domenic> | (and some might assume that a reasonable definition for it is O.[[HasOwnProperty]](P) being true.) |
| 02:06:40
| <ljharb> | right, the handwaveyness of "has a property" |
| 02:06:52
| * darkSeid_ | quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 02:07:17
| <jmdyck> | ok, i can see why people who assumed that would be confused. |
| 02:07:52
| <TimothyGu> | jmdyck: yeah, there isn't a place where "property" of an Object is defined (other than 6.1, where Allen says is for ES programmers) |
| 02:34:23
| <jmdyck> | hm |
| 03:15:00
| <jmdyck> | TimothyGu: I'm not clear on the reason for revising your proposal. |
| 03:18:07
| <jmdyck> | hm |
| 03:29:56
| <jmdyck> | (i.e. revising it away from *all* objects) |
| 03:33:22
| <TimothyGu> | jmdyck: there's no reason for e.g. Proxy objects to have [[OwnProperties]] |
| 03:33:28
| <TimothyGu> | because it'll never get used |
| 03:36:55
| * pandem | quit (Ping timeout: 260 seconds) |
| 03:38:28
| * pandem | joined |
| 03:38:46
| <jmdyck> | Proxies are the only spec-defined objects that wouldn't have an [[OwnProperties]] slot? |
| 03:44:15
| <TimothyGu> | jmdyck: yup |
| 03:46:17
| <TimothyGu> | Module Namespace doesn't *need* one, but it currently defers to OrdinaryGetOwnProperty for Symbol-typed properties while I think it can just return undefined instead. |
| 03:47:44
| <TimothyGu> | in HTML WindowProxy wouldn't have one either |
| 04:02:41
| <TimothyGu> | Domenic: suggested making a new type because of Allen's concern |
| 04:02:44
| <TimothyGu> | "There was a history of people interpreting thing like that as required implementation techniques rather than as specification devices for describing semantics. I didn't want anybody to be misled into thinking such a list had to explicitly exist in an implementation." |
| 04:03:43
| <jmdyck> | I frown at that quote. |
| 04:04:54
| <jmdyck> | The spec is fairly clear that its algorithms and data structures are for merely devices to specify behavior. |
| 04:05:45
| <jmdyck> | I suppose it could say it bold and put stars around it. |
| 04:08:05
| <jmdyck> | It seems a bit silly that this is the one thing that shouldn't be formalized, for fear someone will take it literally. |
| 04:08:29
| <TimothyGu> | jmdyck: so your opinion is that we should use a List? |
| 04:09:39
| <jmdyck> | I don't have an opinion on that yet. |
| 04:13:52
| <jmdyck> | I think I prefer the Property Map. |
| 04:20:18
| <jmdyck> | I don't think I'd object to using a List, but I think you'd still end up presenting this set of operations as (almost) a distinct "data type" that was "implemented" as a List. |
| 04:20:54
| <TimothyGu> | That's one of the conclusions I reached |
| 04:21:15
| <TimothyGu> | The other is that https://tc39.github.io/ecma262/#sec-ordinaryownpropertykeys wouldn't really get simplified much by a List |
| 04:21:41
| <TimothyGu> | and even though it's defined by prose, it's clear and unambiguous, so wouldn't benefit much from changing to a List |
| 04:22:26
| <TimothyGu> | also things like "in ascending numeric index order" are hard to spec with a List |
| 04:23:08
| <jmdyck> | they are? |
| 04:23:47
| <TimothyGu> | yeah |
| 04:23:53
| <TimothyGu> | think about a sparse array |
| 04:24:11
| <TimothyGu> | a[14] = 4; a[3] = 5; a[10] = 6 |
| 04:24:48
| <TimothyGu> | so you either need a heap, or have to sort the List every time OrdinaryOwnPropertyKeys is called |
| 04:25:25
| <TimothyGu> | (assuming we don't keep something handwavey like "in ascending numeric index order") |
| 04:25:33
| <jmdyck> | ah, assuming that. |
| 04:26:03
| <TimothyGu> | it would be odd to be rigorous with String/Symbol but handwavey with indices |
| 04:38:06
| <jmdyck> | Analogy: you could 'implement' the Record type in terms of List, but I don't think it would improve the spec. |
| 04:42:51
| <jmdyck> | Record, Property Map, and Environment Record all have the same underlying idea. It might be nice to pull that out and specify it just once, but it might not be an improvement either. |
| 05:07:14
| * jmdyck | quit (Remote host closed the connection) |
| 05:26:48
| <TimothyGu> | jmdyck is gone, but it's different: records have fixed keys |
| 05:45:00
| * cloudshu | quit (Quit: Connection closed for inactivity) |
| 07:33:46
| * darkSeid_ | joined |
| 07:49:05
| * darkSeid_ | quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 08:05:15
| * shachaf | quit (Ping timeout: 260 seconds) |
| 08:15:34
| * shachaf | joined |
| 08:44:35
| * Guest43015 | quit (Ping timeout: 240 seconds) |
| 08:57:29
| * alextes | joined |
| 08:57:53
| * alextes | changed nick to Guest1642 |
| 09:02:46
| * not-an-aardvark | quit (Quit: Connection closed for inactivity) |
| 09:04:12
| * Guest1642 | quit (Ping timeout: 256 seconds) |
| 10:12:00
| * alextes | joined |
| 10:12:24
| * alextes | changed nick to Guest16262 |
| 11:25:11
| * mylesborins | quit (Quit: farewell for now) |
| 11:25:42
| * mylesborins | joined |
| 12:11:20
| * jmdyck | joined |
| 12:18:10
| * AtumT | joined |
| 12:35:34
| <Domenic> | In general don't let Allen dictate terms too much. He is very conservative on changing anything he was a part of writing. |
| 12:36:19
| <Domenic> | Sorting the list would be what I do, probably. |
| 13:27:14
| <Domenic> | Or leave that party fuzzy, in the spirit of one big change per patch (this big change being the formalization of "has a property") |
| 14:09:54
| * bradleymeck | joined |
| 14:17:35
| * bradleymeck | quit (Ping timeout: 248 seconds) |
| 14:19:09
| * bradleymeck | joined |
| 14:24:50
| * AtumT_ | joined |
| 14:28:30
| * AtumT | quit (Ping timeout: 260 seconds) |
| 14:37:48
| * AtumT | joined |
| 14:39:40
| * AtumT_ | quit (Ping timeout: 256 seconds) |
| 14:51:16
| * gibson042 | joined |
| 15:10:45
| <jmdyck> | TimothyGu: "records have fixed keys": yeah that's mostly true. (There are a few cases where a record has fields added to it after it's created: CreateIntrinsics, ToPropertyDescriptor, OrdinaryGetOwnProperty.) And there are other differences. I'm just saying they share an underlying idea, and musing about pulling that out. |
| 15:11:11
| <jmdyck> | (Certainly not suggesting you should even consider it for this PR.) |
| 15:24:56
| * cloudshu | joined |
| 16:24:36
| * gibson042 | quit (Quit: Leaving.) |
| 16:27:01
| * bradleymeck | quit (Quit: bradleymeck) |
| 16:50:29
| * bradleymeck | joined |
| 17:18:36
| * gibson042 | joined |
| 17:45:04
| * gibson042 | quit (Quit: Leaving.) |
| 18:02:21
| * gskachkov | joined |
| 18:02:23
| * gibson042 | joined |
| 18:09:21
| * gskachkov | quit (Quit: gskachkov) |
| 18:19:06
| * gskachkov | joined |
| 18:21:57
| * darkSeid_ | joined |
| 18:24:09
| * gskachkov | quit (Quit: gskachkov) |
| 18:28:21
| * gskachkov | joined |
| 18:41:27
| * gibson042 | quit (Ping timeout: 240 seconds) |
| 18:42:32
| * gibson042 | joined |
| 19:01:57
| <Bakkot> | since I don't think it's been mentioned here yet: http://www.moddable.com/moddable-zero |
| 19:02:44
| <Bakkot> | a $20 microcontroller with touch screen and wifi, running JS. |
| 19:07:06
| <bradleymeck> | Bakkot: the demo unit they had was pretty good, i've got one but am still wrestlling with battery life vs screen. |
| 19:08:01
| <bradleymeck> | moving to e-ink seems unreasonable but might save a lot of battery life |
| 19:13:18
| * gskachkov | quit (Quit: gskachkov) |
| 19:13:49
| * gskachkov | joined |
| 19:16:37
| * gskachkov | quit (Client Quit) |
| 19:17:07
| * gskachkov | joined |
| 19:28:43
| * gskachkov | quit (Quit: gskachkov) |
| 19:31:32
| * gskachkov | joined |
| 19:34:32
| * gibson042 | quit (Ping timeout: 268 seconds) |
| 19:36:21
| * gskachkov | quit (Ping timeout: 268 seconds) |
| 19:42:34
| * gskachkov | joined |
| 19:50:10
| * gibson042 | joined |
| 20:26:57
| * jwalden | joined |
| 20:36:48
| * darkSeid_ | quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 21:34:10
| * srl295 | quit (Quit: Connection closed for inactivity) |
| 22:07:11
| * darkSeid_ | joined |
| 23:00:30
| * bradleymeck | quit (Quit: ) |
| 23:46:03
| * darkSeid_ | quit (Quit: Textual IRC Client: www.textualapp.com) |