On Wed, Apr 8, 2009 at 7:11 PM, Aaron Boodman <[email protected]> wrote: > > Argh, resending from right adress this time. > > On Wed, Apr 8, 2009 at 7:10 PM, Aaron Boodman <[email protected]> wrote: >> Thanks for forking this. I had started a reply, then forgot to send it. >> >> On Wed, Apr 8, 2009 at 4:57 PM, Nick Baum <[email protected]> wrote: >>> [forking the "Basic how-to steps" thread] >>> I was rereading this, and it seems this wasn't completely resolved. I've >>> summarized the various topics: >>> Syntax >>> It feels like Erik has a somewhat different syntax in mind (still service >>> based, but a little more OO). I think the most useful thing at this point >>> would be for Erik to give an example of what he proposes so we can compare >>> the two. >> >> Yes, agree counterproposals would be easier to digest.
I'll take a swing at something. >> From what I understand of the save() proposal, it doesn't seem to >> provide much value. You get to say foo.save() instead of >> chromium.foos.updateFoo(foo). I guess it's less typing, but if all the >> other functions to get, delete, and create foo objects are on >> chromium.foos, I don't see why it's valuable to have the update >> function not be there. There are other advantages to >> chorium.foos.updateFoo(). It can easily be modified to accept multiple >> foo instances. This could be useful if we need to make sure that a >> bunch of updates happen without repaints between. Fair enough. I do like the update multiple feature. >>> Updates >>> I like Erik's suggestion of keeping change bits, it's clever and transparent >>> to the developer. For update events, do we only send the ID and the fields >>> that have changed? I can see it being useful to have the whole object, but >>> that makes figuring out the changes tricky. Maybe we send all fields in the >>> new object, but only the changed fields in the old object. That makes it >>> easy to find out which ones have changed, while still giving you the whole >>> object. >> >> The change bit idea is interesting. I'm not sure exactly what Erik had >> in mind for how it would work, but I can imagine a few ways: >> >> a) Use javascript prototypes. When you call getThing(), you get back >> an empty object whose __proto__ is the actual object with its fields >> filled in. But when you mutate your thing instance, your writes get >> saved on the empty object. That way if you try to save it again, we >> can tell the difference. interesting idea. I hadn't thought about this. It's pretty simple. Essentially copy on write semantics. >> b) __defineSetter__. We'd intercept writes to fields and save a >> modified bit somewhere. This was what I had in mind. >> I think a) is better. If we find that this is a common problem, we >> could try it out. I'd rather get more APIs built out in the >> dead-simple JSON style though before going deeper on the API >> infrastructure. I agree that a) is nicer. It has a number of nice advantages to it. I'm OK about delaying implementation of this approach so that we can get the APIs nailed down, but I don't think we should decide whether or not we do it based on whether it's an especially common problem. What I'm arguing isn't that it will happen all of the time (it requires multiple updaters to really be a problem), but rather that when it does happen, it will be a subtle and annoying bug to track down, and the way that devs will need to fix it will be worse. Erik --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
