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. > > 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. > > >> 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. > > b) __defineSetter__. We'd intercept writes to fields and save a > modified bit somewhere. > > 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. > > >> Camel-case >> I've seen arguments both ways. I like camelcase better because it's more >> legible, but don't feel strongly about. > > I'm convinced we should change it back to camel case. And I also agree > we should avoid DOM event names if possible. > >> Tabs & windows >> Another difference between tabs and windows is that tabs have prev/next >> history that we should let developers navigate. To me they seem separate >> enough to be worth separating to not get three dozen functions in one >> package, but I don't feel strongly about this. I might sketch out what >> they'd look like if separate. > > Sure, let's try them separated for awhile. > >> Self vs extension >> Is this just a naming issue? Have we decided? > > I'll rename the property in content scripts called 'self' to > 'parentExtension'. > > - a >
--~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
