On Tue, Aug 14, 2012 at 10:33 AM, Andrea Giammarchi < andrea.giammar...@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. > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
