| 02:32 | <Jack Works> | I'm interested in adding a new [[Frozen]] slot on all objects, it's stronger than Object.freeze (let's call it Magic.freeze for now), spec object can opt-in to support this stronger frozen. The result is we will have a generalized method to freeze a native object (if they support this operation). e.g. you can still setDate on a Object.freeze(date), but you cannot do it on a Magic.freeze(date) object. |
| 02:33 | <Jack Works> | It can be a more powerful and generalized solution to cover the Freeze ArrayBuffer I presented before |
| 02:35 | <Jack Works> | Host are encouraged to support freezing internal state when it's meaningful. (e.g. Web URL class can support this, but DOM object should not) |
| 02:35 | <Jack Works> | Is this solution likely to be supported? If not I'll not spend time on preparing and presenting it |
| 02:41 | <Jack Works> | I'm interested in adding a new [[Frozen]] slot on all objects, it's stronger than Object.freeze (let's call it Magic.freeze for now), spec object can opt-in to support this stronger frozen. The result is we will have a generalized method to freeze a native object (if they support this operation). e.g. you can still setDate on a Object.freeze(date), but you cannot do it on a Magic.freeze(date) object. |
| 05:48 | <littledan> | I'm pretty skeptical that this can be made to work well (based on various goals raised by TC39 delegates) |
| 05:49 | <littledan> | Well, I should think more about the opt-in part. Maybe that makes it OK |
| 05:50 | <littledan> | Could you say more about the motivation? |
| 05:52 | <littledan> | I guess the simplest way to do this would be a protocol defining a method (possibly a symbol). Can you explain why you framed this as Magic.freeze(date) and not date.freeze()? |
| 05:57 | <legendecas> | If the NEW freeze is an opt-in feature, how would the NEW freeze ended up being different with Object.freeze when new requirements apply? Broaden the scope of freeze is a breaking change. In that case adding new freeze support might still need a NEW NEW freeze. |
| 06:03 | <littledan> | Well, there are lots of different constraints about such a feature beyond just web compatibility. For example, it should maybe be hookable for user-defined classes, and interaction with proxies and private fields should be defined |
| 06:10 | <littledan> | Such an advanced freeze has been suggested as a replacement for records and tuples, which is probably a reason I am being too negative here, sorry. I think it would not make sense as a replacement because it wouldn't make the structural equality part of R&T work (since it would be weird for the identity of the value to change just because you Magic.freeze it). But it's OK for you to have that as a non-goal for this other feature (as long as it is not claimed to subsume R&T) |
| 06:36 | <littledan> | I really think that immutability needs to be part of the design of the class, and not bolted on later through some external function called on an instance. Temporal is an immutable replacement for date, and includes methods for changing one component without mutation, which are idiomatically done on date through mutation. |
| 06:37 | <littledan> | Another example is that Tuples are proposed with their array-by-copy methods, and they would seem somehow broken without them (or with the normal array mutation methods) |
| 07:57 | <Jack Works> | I really think that immutability needs to be part of the design of the class, and not bolted on later through some external function called on an instance. Temporal is an immutable replacement for date, and includes methods for changing one component without mutation, which are idiomatically done on date through mutation. |
| 16:03 | <Jack Works> | Is the SES meeting collect the attendee every time like incubator call? Otherwise it will be always too late for me |
| 16:13 | <shu> | i think the SES meetings are always at a fixed time because they usually have a fixed attendee list, whereas the incubator calls are re-scheduled each time because the attendee list is different each time |
| 16:14 | <Jack Works> | i think the SES meetings are always at a fixed time because they usually have a fixed attendee list, whereas the incubator calls are re-scheduled each time because the attendee list is different each time |
| 16:16 | <shu> | but i'm not part of that group, please reach out to someone there about how to accommodate APAC delegates |
| 16:19 | <Jack Works> | Thanks |
| 16:20 | <littledan> | yeah, we could definitely move that meeting; it was moved previously to be more Europe-friendly. Probably email Kris Kowal for next steps here. It'd be great to have you in the calls--I think everyone in the group really likes your perspective on these topics. |
| 16:20 | <littledan> | (narrator: the time they chose was not very Europe-friendly) |
| 16:24 | <littledan> | anyway I'll raise this at our meeting in half an hour |
| 16:28 | <Jack Works> | anyway I'll raise this at our meeting in half an hour |
| 16:29 | <Jack Works> | And I have another question, how should we handle SES meeting and TG3 meeting, they looks like a duplicate in some part |
| 16:30 | <littledan> | Jack Works: Do you mean in their contents, or scheduling? |
| 16:31 | <Jack Works> | Scheduling maybe? But iirc tg3 don't have regular currently |
| 16:32 | <littledan> | about scheduling, we were thinking of having them be in the same timeslot, but then canceling SES when TG3 overlaps |
| 16:32 | <littledan> | so SES is weekly and TG3 is monthly |
| 16:33 | <littledan> | about contents: We discussed this in the past--I think they have very different scopes. The SES meeting is about discussing various proposals from the point of view that object-capability security is meaningful, and in TG3, I think the first items of business include what security models to consider |
| 16:35 | <Jack Works> | Oh sure, they're also covering spectrum (is that word) and things like that? |
| 16:36 | <littledan> | Spectre? Well, I don't know, I've been a bit out of the loop on TG3 honestly |
| 19:21 | <mpcsh> | where does the code for tc39.es live? just notice Myles' last name is misspelled here |
| 19:21 | <ryzokuken> | tc39.github.io? |
| 19:22 | <ryzokuken> | https://github.com/tc39/tc39.github.io/ |
| 19:52 | <littledan> | No, the link provided lives at github.com/tc39/code-of-conduct |
| 19:53 | <littledan> | (the list of CoC members has long been out of date. I hope the CoC committee fixes it soon.) |
| 19:53 | <ryzokuken> | ah, makes sense. Each tc39.es/$something is from a repo named $something |