- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 30 Aug 2011 19:22:04 -0700
On Tue, Aug 30, 2011 at 12:30 PM, Ryosuke Niwa <rniwa at webkit.org> wrote: > On Tue, Aug 30, 2011 at 12:21 PM, Ehsan Akhgari <ehsan at mozilla.com> wrote: > >> On 11-08-30 3:15 PM, Ryosuke Niwa wrote: >> >>> ? ?1. Should Transaction have reapply property or not? ?It appears that >>> some >>> >>> ? ?of us (e.g. me, Annie, Alex) want it for semantical clarity while >>> others >>> ? ?(e.g. Jonas and Ehsan) doesn't wait to avoid code duplication and to >>> simply >>> ? ?the API. >>> >> >> I still think that if we can design an API which discourages code >> duplication, we probably should. >> > > (I feel like we're bikesheding here but) authors can do that by omitting > reapply as in {'apply': ..., 'unapply': ...}. First of all people tend to copy and be inspired by what other people do, so it seems very likely that people would end up duplicating code not realizing that the reapply function is optional. Second, I think you brought up really good arguments for why the reapply behavior often needs to be slightly different than the apply behavior. As you pointed out this would be awkward if you simply left out the reapply function under your proposal. This is why I suggested we add the boolean argument passed to the apply function which is indicates if it's the first apply call, or a subsequent one. I'm really failing to think of a case when you'd really want to have apply and reapply as separate callbacks. Even in the most trivial cases it seems like it would lead to code duplication which is something that even the most basic developers try to avoid. And especially in more complex scenarios like collaborative editors it seems like you really wouldn't want to duplicate the logic between apply and reapply. So once we have the boolean argument to apply, I fail to see any cases where the reapply approach is better. I'd love to see some examples if you have any? / Jonas
Received on Tuesday, 30 August 2011 19:22:04 UTC