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. br On Tue, Aug 14, 2012 at 11:30 AM, Alex Russell <[email protected]>wrote: > > On Tue, Aug 14, 2012 at 10:33 AM, Andrea Giammarchi < > [email protected]> 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. >> >>
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
