- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 9 Aug 2011 15:45:04 -0700
On Tue, Aug 9, 2011 at 3:29 PM, Annie Sullivan <sullivan at chromium.org> wrote: > On Tue, Aug 9, 2011 at 6:25 PM, Jonas Sicking <jonas at sicking.cc> wrote: >> On Tue, Aug 9, 2011 at 2:59 PM, Annie Sullivan <sullivan at google.com> >> wrote: >> > On Tue, Aug 9, 2011 at 4:59 PM, Jonas Sicking <jonas at sicking.cc> wrote: >> >> >> >> On Tue, Aug 9, 2011 at 12:03 PM, Ryosuke Niwa <rniwa at webkit.org> wrote: >> >> >> >> > On Tue, Aug 9, 2011 at 1:17 AM, Jonas Sicking <jonas at sicking.cc> >> >> > wrote: >> >> > >> >> >> On Tue, Aug 9, 2011 at 12:42 AM, Ryosuke Niwa <rniwa at webkit.org> >> >> >> wrote: >> >> >> > On Tue, Aug 9, 2011 at 12:31 AM, Jonas Sicking <jonas at sicking.cc> >> >> >> wrote: >> >> >> ?>> Likewise I still haven't heard of any examples where the >> >> >> apply function >> >> >> >> isn't simply init+reapply. So it still seems better to me to have >> >> >> >> a >> >> >> >> init/apply/unapply split rather than a apply/reapply/unapply >> >> >> >> split. >> >> >> > >> >> >> > This is also pending for developer feedback. >> >> >> >> >> > >> >> > I've talked about this with Alex, and we both agreed that having >> >> > apply/reapply split is cleaner because in many cases you'd like to >> >> > know >> >> > whether you're in redo or not. ?i.e. more work is done in reapply >> >> > than >> >> > in >> >> > apply. >> >> > >> >> >> >> Could you please provide examples. I feel like I'm fighting an elusive >> >> shadow. >> >> >> >> I.e. please provide an example where "apply" isn't just init+reapply. >> >> "There >> >> are many cases" isn't a particularly compelling argument unless you can >> >> show >> >> these cases :-) >> >> >> >> And ideally also some estimate how common that case will be compared to >> >> "apply" simply being init+reapply. This is important since if that is >> >> very >> >> rare, people can always implement it themselves using init+reapply >> >> semantics >> >> by having a flag on the object which indicates if you're in the first >> >> call >> >> or not. >> > >> > >> > As an author, I would really love to have as much information as >> > possible >> > about what the user was trying to do. I might want to keep my own >> > bookkeeping about what is going on in the document, in some other format >> > besides HTML. >> > For example, if I were writing a collaborative editing app, and I >> > decided >> > that any user could unapply/reapply any change, I might end up with a >> > sequence like this: >> > Susan made change X >> > Bob unapplied change X >> > Susan reapplied change X >> > Bob unapplied change X >> > Susan reapplied change X >> > ... >> > It would be great to show that in the document history view of my app >> > very >> > clearly. I think knowing that a change was unapplied/reapplied instead >> > of >> > just showing text diffs between revisions would be great. >> >> I'm not quite sure I understand what API you are arguing for and how >> that API would help you. >> >> If you're wanting to show that a change was unapplied/reapplied, >> wouldn't you also want to show who did the unapply/reapply? In that >> case you'd have to do your own book keeping anyway, no? > > Yes, if you're keeping additional metadata, you have to do your own > bookkeeping, but it's much easier to get the info about whether the change > was applied or reapplied if the API is set up so that you have an > apply/reapply instead of init/apply. We're talking about a line of code setting a single boolean flag. That's not a whole lot of code. And for a very narrow usecase that can hardly be considered the common usecase. I.e. wanting to display if a change has been unapplied/reapplied, but not wanting to show any other metadata about the change (such as who or when), in a collaborative editor. Any feature that is so easy to replace and is going to be used that rarely I'd cut in a heartbeat. It did sound like selection management could be a much stronger use case though. / Jonas
Received on Tuesday, 9 August 2011 15:45:04 UTC