+1. An update the debugger window title once the method is implemented. :) Esteban A. Maringolo
2014-06-15 10:15 GMT-03:00 Esteban Lorenzano <[email protected]>: > For me, having to choose a protocol before creating the method is contrary to > TDD spirit of “go to the green as fast as you can, clean later”. > So yes, instead enhance it, I would directly remove the protocol chooser in > that workflow… > > Esteban > > On 15 Jun 2014, at 10:11, Ben Coman <[email protected]> wrote: > >> Ben Coman wrote: >>> Just surveying opinion, when pressing the 'Create' (method) button in the >>> debugger, how critical do people consider the need for the Protocol Chooser >>> at that time? Personally I find it interrupts my flow, since often I don't >>> feel comfortable with the conventions to choose which protocol it should go >>> in. It makes me go searching in another browser to try to determine the >>> convention from other existing methods. A few options to start with: >>> 1. Like it just the way it is. >>> 2. Dump the new method in unclassified and clean up later (plus a protocol >>> sorting refactoring tool) >>> 3. Having Protocol Chooser provide a short list of suggestions, perhaps >>> somehow indicating the rule used and weighting. For example: "accessors >>> (100 methods matching instance variables)" ; "testing (20 items match 'is' >>> prefix)"". >>> btw, In 2.0 the Protocol Chooser came up with a massive list (actually >>> where this survey question stems from) but in 3.0 the Protocol Chooser >>> comes up empty for my use cases. Can anyone suggest an example in 3.0 that >>> populates the Protocol Chooser? >> doh! I only needed to start typing to populate the Protocol Chooser. Now it >> still presents too many choices for my sensibilities. >> cheers -ben >> > >
