DNU Create button auto extension category

We are working on making sure that in the future it will be easier to add new command to calypso. 

- First step is to put calypso/commander/system commander in the Pharo repo (because we cannot have to do 4 PR for a stupid fix).

- Second we are experimenting with a new version of commander that is less based on class creation but more on objects. 

We are validating it with real examples, and soon we will release an alpha version and work on automatic migration. 

The goal is to integrate this new version to Spec2.0. 

- The goal is to use all that for the 

- DrTests

- Spec2

- Refactoring improvements. 

Stef

On Sun, 12 May 2019 at 15:41, Tim Mackinnon <[hidden email]> wrote:

My point was that in general - method categorisation has degraded (not just your debugger case, but in a broader sense).

Nautilus used to infer method protocols , and if not inferred, you used to see protocols already in your package... now you basically have to type out protocols and search for them every time.

I don’t think you can even bulk categorise methods either.

I keep meaning to have a look, as it’s all quite annoying and doesn’t really encourage you to categorise anything as it’s too much like hard work.

With Calypso I've had some success using  Protocols Pane > Categorize all uncategorized.

but as an after-the-fact clean up maybe not what your looking for.

cheers -ben

 

Tim

Sent from my iPhone

On 12 May 2019, at 07:30, Ben Coman <[hidden email]> wrote:

>>> On 11 May 2019, at 18:07, Ben Coman <[hidden email]> wrote:
>>>
>>> Currently when a DNU occurs we get this cool <Create> button,
>>> but when this presents the dialog "New Protocol Name" I get a blank
>>> list and the default is "as yet unclassified" and I end up with a heap
>>> of such unclassified methods to sort later.
>>>
>>> I am wondering if it could be smarter when tests are being run.  A
>>> reasonable assumption could be that the test's package name is closely
>>> related to the likely extension package name.
>>> So for a DNU, I wonder if the debugger could walk the stack to
>>> discover if a TestCase subclass was on the stack (e.g. MyTestCase) and
>>> then determine which package MyTestCase belonged to, and present that
>>> as a choice for "New Protocol Name", helping categorize extension
>>> methods.
>>>
>>> I've started to play like this...
>>>
>>> TestCase subclass: #MyTestRoot
>>>
>>> MyTestRoot >> runCase
>>>   [ super runCase ]
>>>       on: MessageNotUnderstood
>>>       do: [ :ex |
>>>             "do something here, but for now..."
>>>              ex pass
>>>              ].
>>>
>>> but before getting to deep, I'm seeking suggestions/solutions from the
>>> community.
>
>> On Sun, 12 May 2019 at 05:06, Tim Mackinnon <[hidden email]> wrote:
>>
>> It’s a good point Ben - in fact categorisation in general has not been finished in pharo7 -
>> the move to Calypso lost smart method categories and its on the todo list to fix and improve it.
>
> I don't think this is related to Calypso, more to do with the debugger.
> I got what I wanted with the following change...
> ```
> DoesNotUnderstandDebugAction>>defaultProtocol   "new method"
>        "Facilitate  DNU with TDD creating extension methods by
> suggesting that as default protocol"
>        | interruptedContext candidateContext |
>        "self halt"
>        interruptedContext := self interruptedContext.
>        candidateContext := interruptedContext sender.
>        [ candidateContext isNil or: [ candidateContext contextClass
> isKindOf: TestCase class ] ]
>                whileFalse: [ candidateContext := candidateContext sender ].
>        candidateContext ifNotNil: [
>                | testPackage dnuPackage|
>                dnuPackage := interruptedContext receiver class package.
>                testPackage := candidateContext contextClass package.
>                (testPackage = dnuPackage) ifFalse: [ ^ '*', testPackage name ].
>                ].
>        ^'as yet unclassified'
>
> DoesNotUnderstandDebugAction>>executeAction  "diff modified method"
>        | msg msgCategory chosenClass exception |
>        msg := self interruptedContext tempAt: 1.
>        exception := self interruptedContext tempAt: 2.
>        (exception class == ClassNotUnderstood) ifTrue: [
>                self createMissingClassWith: exception variableNode
> in: self interruptedContext ].
>        chosenClass := self
>                askForSuperclassOf: self interruptedContext receiver class
>                toImplement: msg selector
>                ifCancel: [^self].
> -        msgCategory := (self askForCategoryIn: chosenClass default:
> 'as yet unclassified' ).
> +        msgCategory := (self askForCategoryIn: chosenClass default:
> self defaultProtocol).
>      self  session
>                implement: msg
>                classified: msgCategory
>                inClass: chosenClass
>                forContext: self interruptedContext.
>        self debugger selectTopContext
> ```
>
> Tim, Can you trial this with your Exercism Die exercise?
>
> Alternatively an isolated test...
> ```
> Object subclass: MyApp ... package: 'MyPackage'
>
> TestCase subclass: MyTestCase ... package: 'MyPackage'
>
> MyTestCase >> testAutoExtensionProtocol
>    MyApp new unknown
> ```
>
> Run the test then click <Create> button to add following method with
> default protocol... as yet unclassified
> ```
> MyApp >> unknown
>      42 unknown
> ```
>
> Click <Create> button to add method with default protocol...  *MyPackage
>
> cheers -ben
>
> P.S. Next question is how to create a unit test for such behaviour ??
>