On Mon, Jun 17, 2013 at 3:35 PM, Mark S. Miller <erights@google.com> wrote:
> On Mon, Jun 17, 2013 at 11:59 AM, Rick Waldron <waldron.rick@gmail.com>wrote:
>
>>
>> On Mon, Jun 17, 2013 at 5:55 AM, François REMY <
>> francois.remy.dev@outlook.com> wrote:
>>
>>> As far as I know, Object.observe only works for "plain objects" i.e. it
>>> doesn't fire when properties with getter/setter are changed. If you are
>>> working on a DOM spec, it's very likely you're in this specific case.
>>>
>>
>> Object.observe works with all objects. Some objects, such as Dates, Maps,
>> Sets, WeakMaps and likely WeakSets will not trigger change events when
>> their internal data is modified via methods (setTime, set, add, delete,
>> etc), but defining and later modifying expando properties will trigger a
>> change. (This list is not exhaustive)
>>
>
> Hi Rick, I never recall deciding that they would not.
>
Exactly, we haven't :)
I think at least Date, Map and Set should, but we haven't addressed this
yet and have plenty of ES6 to finish before we can really look closer (as a
committee). Above, I'm merely illustrating the current state—I apologize if
that was unclear.
> In general, mutable abstractions should consider sending synthetic change
> notifications if anyone is listening. We need to take it on a case by case
> basis per mutable abstraction, and on the design of these particular
> synthetic change notifications. But I see no immediate reason why the
> non-Weak* ones above would be candidates. Even the Weak* ones perhaps, if
> we're careful enough with the security issues.
>
I'm +1 to the non-Weak* APIs, but agree that we should at least explore the
safe ways to do the Weak* APIs.
Rick