2015-03-10 14:13 GMT+01:00 Ben Coman <btc@openinworld.com>:
2015-03-10 13:27 GMT+01:00 Peter Uhnák <i.uhnak@gmail.com>:
On Tue, Mar 10, 2015 at 1:23 PM, Joachim Tuchel <jtuchel@objektfabrik.de
wrote:
#doWithIndex: ?
doWithIndex: elementAndIndexBlock "Use the new version with consistent naming" ^ self withIndexDo: elementAndIndexBlock
On Tue, Mar 10, 2015 at 8:36 PM, Thierry Goubier <
thierry.goubier@gmail.com> wrote:
And one has to guess that elementAndIndexBlock means
[:each :i | ... ] ? (and of course not [:i :each | ... ] )
The Principle Of Least Surprise would imply that the variables appear in the same order that they appear in the method name. Of course that doesn't mean you don't get surprised sometimes. Are there any that don't follow that rule? We should consider fixing them.
In Pharo 4. GLMTableColumn>>#modifiedBlock: anObject. I tried to follow the trail and it's a three arguments block, according to GLMTreeMorphNodeModel>>#rowMorphForColumn: , since we see: aGlamourColumn modifiedBlock cull: contentMorph text cull: self item cull: self containerTree glamourPresentation Following senders, I have GLMTablePresentation>>column: aBlockOrString evaluated: aBlock modified: aModifiedBlock, (still no documentation) and: GTObjectVariablesBrowser>>variablesIn: composite where I find: column: 'Value' evaluated: [:assoc | GTObjectPrinter new asTruncatedTextFrom: assoc value ] modified: [:newValue :assoc :presentation | self updateInstanceVariable: assoc key from: presentation entity basedOn: newValue. presentation update ]; Now, I know :) A good experience: use a finder or spotter, search for senders of cull:cull:cull:. I choose the first one I found for the example above (I have a memory of some which were annoying, in Morphic or Spec, but couldn't remember which ones). It would be interesting if something like autocompletion could supply the
template for the block.
Ouch. It would not be easy, but possible. A pragma ? ;) Thierry