Experimental implementation of Object.observe & JS Utility library now available

Andrea Giammarchi andrea.giammarchi at gmail.com
Tue Aug 14 14:31:06 PDT 2012

if fixed-ish shape is not a performance issue then is fine, still I would
put in this fixed-ish shape a currentValue property, not only the oldValue
one, to avoid constantly and repeated checks to record.object[record.name]

If not holded, GC has to take care of them in any case, isn't it?
I know objects as arguments are better/easier to extend/maintain than fixed
callback contracts/signatures but sometimes the creation of an object per
each callback call, and with this mechanism I can see many of them, could
have a not desired cost in therms of memory and performances.

Thanks in any case for the reply.


On Tue, Aug 14, 2012 at 11:30 AM, Alex Russell <slightlyoff at google.com>wrote:

> On Tue, Aug 14, 2012 at 10:33 AM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>> just seen it, looks like an improved alternative to the good old, non
>> standard, Object.prototype.watch
> Key differences include:
>   * unlike watch(), you can be informed not only of deletions but also
> additions to objects
>   * delivery is async-ish (huzzah!)
>> ... but
>>    1. records are not "struct like", properties might be or might not be
>>    there rather than being there with undefined values ... is this heading to
>>    not optimal performances in V8 and others?
>> I don't understand. New objects with fixed-ish shape have fixed-ish shape
> through their lifetimes. It's unclear what the problem is here.
>>    1. how is the memory consumption preserved with freshly new created
>>    record objects, rather than a single callback as entry point and simply
>>    oldValue, newValue passed as arguments?
>> These objects are disposed at the end of the current turn (assuming you
> don't hold on to them forever).
>>    1. why the callback is not simply something like observer(type,
>>    object, property, oldValue, newValue) so that a single callback can be
>>    still recyclable and no object is created per each change, plus it's easier
>>    to retrieve the new value rather than passing through record.object[
>>    record.name] ?
>> Having the full list is critical for dealing with inter-related changes
> that happen in a second turn. You often care about the high-level semantic
> action, not just the immediate change to some property.
>>    1. what is the context of each notify call? (this might be in specs
>>    already, so I'll check there too)
>> I know it's strawman already but if anyone can explain me these points
>> that would be great, cheers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120814/fe50b496/attachment.html>

More information about the es-discuss mailing list