I managed to find some time to progress with my Smalltalk / Pharo learning and am going through the Spec booklet. I noticed that autocompletion most of the times works excellent, sometimes it struggles. For instance, if you prepare CustomerSatisfaction >> initializeWidgets buttonBad := self instantiate: ButtonPresenter. and then start to write buttonBad label: ... in the same method, the #label: selector is found immediately. However, if you say CustomerSatisfaction >> initializeWidgets buttonBad := self newButton. where ComposablePresenter >> newButton ^ self instantiate: ButtonPresenter and inherited by CustomerSatisfaction, then the #label: selector is not found by autocompleter (in the menu of choices). I'm just curious why is that so. For a novice, autocompleter is a life saver :-) Best wishes, Tomaz
I found the cause - I created the #buttonBad accessing methods with code (re)factoring (generate accessors), and in this case the accessors are made in this fashion: CustomerSatisfaction >> buttonBad: *anObject *buttonBad := *anObject *It's better to use CustomerSatisfaction >> buttonBad: *aComposablePresenterClass *buttonBad := *aComposablePresenterClass *as this method is doing: ComposablePresenter >> instantiate: aComposablePresenterClass "Instantiate a ComposablePresenter subclass and set its instance owner" ^ aComposablePresenterClass owner: self To find the cause, I used the debugger extensively and found the core logic in ECInstVarTypeGuesser >> perform method - it was quite an exercise! Best wishes, Tomaz -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
On 16 Jun 2019, at 08:41, eftomi <tomaz.turk@ef.uni-lj.si> wrote:
I found the cause - I created the #buttonBad accessing methods with code (re)factoring (generate accessors), and in this case the accessors are made in this fashion:
CustomerSatisfaction >> buttonBad: *anObject *buttonBad := *anObject
*It's better to use
CustomerSatisfaction >> buttonBad: *aComposablePresenterClass *buttonBad := *aComposablePresenterClass
*as this method is doing:
ComposablePresenter >> instantiate: aComposablePresenterClass "Instantiate a ComposablePresenter subclass and set its instance owner"
^ aComposablePresenterClass owner: self
Yes, the problem is that the Type guesser guesses types, but then they are used as if they would be the truth⦠this is done in two cases: 1) names of arguments, as you have seen: if you call it âanArrayâ, the code completion will only show you method for Array. 2) sends to Globals that are classes: every send of the kind âClass somethingâ will be types as âinstance of Classâ. Which is not even true for #new in all cases (see String). What would be better: distinguish between âtypesâ and âtype guessâ. The later we should use to sort the results, not to restrict it.
To find the cause, I used the debugger extensively and found the core logic in ECInstVarTypeGuesser >> perform method - it was quite an exercise!
Wow! that is a real execise. Marcus
participants (3)
-
eftomi -
Marcus Denker -
Tomaž Turk