00:33:05  * not-an-aardvarkjoined
00:33:39  * Fishrock123quit (Remote host closed the connection)
00:39:59  * Fishrock123joined
00:40:00  * Fishrock123quit (Remote host closed the connection)
01:01:38  * Fishrock123joined
01:01:41  * Fishrock123quit (Remote host closed the connection)
01:24:45  * jwaldenquit (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  * Fishrock123joined
01:43:21  * Fishrock123quit (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  * pandemquit (Ping timeout: 260 seconds)
03:38:28  * pandemjoined
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  * jmdyckquit (Remote host closed the connection)
05:26:48  <TimothyGu>jmdyck is gone, but it's different: records have fixed keys
05:45:00  * cloudshuquit (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  * shachafquit (Ping timeout: 260 seconds)
08:15:34  * shachafjoined
08:44:35  * Guest43015quit (Ping timeout: 240 seconds)
08:57:29  * alextesjoined
08:57:53  * alexteschanged nick to Guest1642
09:02:46  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
09:04:12  * Guest1642quit (Ping timeout: 256 seconds)
10:12:00  * alextesjoined
10:12:24  * alexteschanged nick to Guest16262
11:25:11  * mylesborinsquit (Quit: farewell for now)
11:25:42  * mylesborinsjoined
12:11:20  * jmdyckjoined
12:18:10  * AtumTjoined
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  * bradleymeckjoined
14:17:35  * bradleymeckquit (Ping timeout: 248 seconds)
14:19:09  * bradleymeckjoined
14:24:50  * AtumT_joined
14:28:30  * AtumTquit (Ping timeout: 260 seconds)
14:37:48  * AtumTjoined
14:39:40  * AtumT_quit (Ping timeout: 256 seconds)
14:51:16  * gibson042joined
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  * cloudshujoined
16:24:36  * gibson042quit (Quit: Leaving.)
16:27:01  * bradleymeckquit (Quit: bradleymeck)
16:50:29  * bradleymeckjoined
17:18:36  * gibson042joined
17:45:04  * gibson042quit (Quit: Leaving.)
18:02:21  * gskachkovjoined
18:02:23  * gibson042joined
18:09:21  * gskachkovquit (Quit: gskachkov)
18:19:06  * gskachkovjoined
18:21:57  * darkSeid_joined
18:24:09  * gskachkovquit (Quit: gskachkov)
18:28:21  * gskachkovjoined
18:41:27  * gibson042quit (Ping timeout: 240 seconds)
18:42:32  * gibson042joined
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  * gskachkovquit (Quit: gskachkov)
19:13:49  * gskachkovjoined
19:16:37  * gskachkovquit (Client Quit)
19:17:07  * gskachkovjoined
19:28:43  * gskachkovquit (Quit: gskachkov)
19:31:32  * gskachkovjoined
19:34:32  * gibson042quit (Ping timeout: 268 seconds)
19:36:21  * gskachkovquit (Ping timeout: 268 seconds)
19:42:34  * gskachkovjoined
19:50:10  * gibson042joined
20:26:57  * jwaldenjoined
20:36:48  * darkSeid_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:34:10  * srl295quit (Quit: Connection closed for inactivity)
22:07:11  * darkSeid_joined
23:00:30  * bradleymeckquit (Quit: )
23:46:03  * darkSeid_quit (Quit: Textual IRC Client: www.textualapp.com)