Experimental implementation of Object.observe & JS Utility library now available
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...
More information about the es-discuss