Survey - needing Protocol Chooser when creating methods from the debugger
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? cheers -ben
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
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 <btc@openInWorld.com> 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
+1 organization of the protocols is part of refactoring EstebanLM wrote
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â¦
-- View this message in context: http://forum.world.st/Survey-needing-Protocol-Chooser-when-creating-methods-... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
+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 <estebanlm@gmail.com>:
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 <btc@openInWorld.com> 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
I vote for just letting the method unclassified and a test case detecting unclassified methods to not forget classifying the method later On Jun 15, 2014 10:04 AM, "Ben Coman" <btc@openinworld.com> 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?
cheers -ben
Agree. Except that codecritics is better for this and I think already has this rule On Jun 15, 2014 6:10 PM, "Gabriel Cotelli" <g.cotelli@gmail.com> wrote:
I vote for just letting the method unclassified and a test case detecting unclassified methods to not forget classifying the method later On Jun 15, 2014 10:04 AM, "Ben Coman" <btc@openinworld.com> 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?
cheers -ben
participants (6)
-
Attila Magyar -
Ben Coman -
Damien Cassou -
Esteban A. Maringolo -
Esteban Lorenzano -
Gabriel Cotelli