Thanks Joachim and Peter ... Its worked regards Sanjay ----- --- Regards, Sanjay -- View this message in context: http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the-... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Yes usually I have to open the code and see, use intuition or write a sample code to find out incidentally here I also have to figure out which is the current and which is the deprecated version ... well thats it sanjay --- Sanjay Minni +91-9900-902902 http://in.linkedin.com/in/sanjayminni On Tue, Mar 10, 2015 at 5:57 PM, Thierry Goubier [via Smalltalk] < ml-node+s1294792n4810931h65@n4.nabble.com> wrote:

And one has to guess that elementAndIndexBlock means

[:each :i | ... ] ? (and of course not [:i :each | ... ] )

I'm allways looking for senders with that type of code ;) arguments to blocks are usually not documented.

Thierry

2015-03-10 13:27 GMT+01:00 Peter Uhnák <[hidden email] <http:///user/SendEmail.jtp?type=node&node=4810931&i=0>>:

...

On Tue, Mar 10, 2015 at 1:23 PM, Joachim Tuchel <[hidden email] <http:///user/SendEmail.jtp?type=node&node=4810931&i=1>> wrote:

...

#doWithIndex: ?

doWithIndex: elementAndIndexBlock "Use the new version with consistent naming" ^ self withIndexDo: elementAndIndexBlock

------------------------------ If you reply to this email, your message will be added to the discussion below:

http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the-... To unsubscribe from when iterating over a collection how to determine the current objects index, click here <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&nod...> . NAML <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instant...>

----- --- Regards, Sanjay -- View this message in context: http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the-... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

On 10 Mar 2015, at 14:25, Joachim Tuchel <jtuchel@objektfabrik.de> wrote:

Sounds like a bad naming to me. I don't see why withIndexDo is any better. It even contradicts the order of the arguments. And it is Proprietary to Pharo.

No, if you look a the timeStamp it was done in 1997 by Dan.

Joachim

Am 10.03.2015 um 13:39 schrieb Sanjay Minni <sm@planage.com <mailto:sm@planage.com>>:

...

Yes usually I have to open the code and see, use intuition or write a sample code to find out incidentally here I also have to figure out which is the current and which is the deprecated version ... well thats it

sanjay

--- Sanjay Minni +91-9900-902902 http://in.linkedin.com/in/sanjayminni <http://in.linkedin.com/in/sanjayminni> On Tue, Mar 10, 2015 at 5:57 PM, Thierry Goubier [via Smalltalk] <[hidden email] <x-msg://6/user/SendEmail.jtp?type=node&node=4810945&i=0>> wrote: And one has to guess that elementAndIndexBlock means

[:each :i | ... ] ? (and of course not [:i :each | ... ] )

I'm allways looking for senders with that type of code ;) arguments to blocks are usually not documented.

Thierry

2015-03-10 13:27 GMT+01:00 Peter Uhnák <[hidden email] <http://user/SendEmail.jtp?type=node&node=4810931&i=0>>: On Tue, Mar 10, 2015 at 1:23 PM, Joachim Tuchel <[hidden email] <http://user/SendEmail.jtp?type=node&node=4810931&i=1>> wrote: #doWithIndex: ?

doWithIndex: elementAndIndexBlock "Use the new version with consistent naming" ^ self withIndexDo: elementAndIndexBlock

If you reply to this email, your message will be added to the discussion below: http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the-... <http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the-...> To unsubscribe from when iterating over a collection how to determine the current objects index, click here <applewebdata://B2A91C9C-780D-40B2-9C35-3155BCAFCB80>. NAML <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instant...> --- Regards, Sanjay

View this message in context: Re: when iterating over a collection how to determine the current objects index <http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the-...> Sent from the Pharo Smalltalk Users mailing list archive <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at Nabble.com <http://nabble.com/>.

sorry folks ... so back to terra firma ... 1. Is there any way to query an object to finds its index value in the original collection ... say when all the objects from a collection are displayed and user clicks on one item - I want to locate the object back in the collection. Knowing the index for me would be most efficient. 2. ... also Is there any way to know if I am on the last element ... otherwise I will have to explicitly store the index values ... regards Sanjay jtuchel wrote

Marcus

So sorry for this false accusation. It is proprietary in Squeak. And even if it was Dan's idea to rename it, I'd like to learn more about the reasoning. My understanding would be:

[...]

----- --- Regards, Sanjay -- View this message in context: http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the-... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

(aCollection indexOf: anObject) = aCollection size

Am 10.03.2015 um 14:47 schrieb Sanjay Minni <sm@planage.com>:

sorry folks ...

so back to terra firma ...

1. Is there any way to query an object to finds its index value in the original collection ... say when all the objects from a collection are displayed and user clicks on one item - I want to locate the object back in the collection. Knowing the index for me would be most efficient.

2. ... also Is there any way to know if I am on the last element ...

otherwise I will have to explicitly store the index values ...

regards Sanjay

jtuchel wrote

...

Marcus

So sorry for this false accusation. It is proprietary in Squeak. And even if it was Dan's idea to rename it, I'd like to learn more about the reasoning. My understanding would be:

[...]

----- --- Regards, Sanjay -- View this message in context: http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the-... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

NorbertHartl wrote

anObject = aCollection last

Of course the above and #indexOf: will only work if there are no duplicates in the collection and #indexOf: will require a lot of extra iterations. If you need the indices associated to the objects, maybe you should wrap them e.g. "indexedObjects := objects collectWithIndex: [ :e :i | IndexedObject object: e index: i ]". Then you can cleanly access the indices whenever you want. ----- Cheers, Sean -- View this message in context: http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the-... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Le 10/3/15 14:40, Joachim Tuchel a écrit :

Marcus So sorry for this false accusation. It is proprietary in Squeak. And even if it was Dan's idea to rename it, I'd like to learn more about the reasoning. My understanding would be: #do: iterates over a collection #doWithIndex: iterates over a collection and also keeps track of the current index. Sounds very consistent to me. the most important thing I want the machine to do is iterate over the collection, and the index thing is just a variant thereof. #do: iterates over a collection #withIndexDo: keeps track of the index while iterating over a collection

Sounds clumsy to me. Introduces incompatibilities for not much value. If people complained about #do: as not intentioon revealing and opted to rename it to something like #withEachDo: , then I c +1

ould understand it. The variant could be #withEachDoIndexed: But not that one ;-) ... but this is completely off-topic of course... Joachim

...

Marcus Denker <marcus.denker@inria.fr> hat am 10. März 2015 um 14:32 geschrieben:

...

On 10 Mar 2015, at 14:25, Joachim Tuchel < jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de>> wrote:

Sounds like a bad naming to me. I don't see why withIndexDo is any better. It even contradicts the order of the arguments. And it is Proprietary to Pharo. No, if you look a the timeStamp it was done in 1997 by Dan.

...

Joachim

Am 10.03.2015 um 13:39 schrieb Sanjay Minni < sm@planage.com <mailto:sm@planage.com>>:

...

Yes usually I have to open the code and see, use intuition or write a sample code to find out incidentally here I also have to figure out which is the current and which is the deprecated version ... well thats it sanjay

--- Sanjay Minni +91-9900-902902 http://in.linkedin.com/in/sanjayminni

On Tue, Mar 10, 2015 at 5:57 PM, Thierry Goubier [via Smalltalk] <[hidden email]> wrote:

And one has to guess that elementAndIndexBlock means [:each :i | ... ] ? (and of course not [:i :each | ... ] ) I'm allways looking for senders with that type of code ;) arguments to blocks are usually not documented. Thierry

2015-03-10 13:27 GMT+01:00 Peter Uhnák <[hidden email] <http:/user/SendEmail.jtp?type=node&node=4810931&i=0>>:

On Tue, Mar 10, 2015 at 1:23 PM, Joachim Tuchel <[hidden email] <http:/user/SendEmail.jtp?type=node&node=4810931&i=1>> wrote:

#doWithIndex: ?

doWithIndex: elementAndIndexBlock "Use the new version with consistent naming" ^ self withIndexDo: elementAndIndexBlock

------------------------------------------------------------------------ If you reply to this email, your message will be added to the discussion below: http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the-...

To unsubscribe from when iterating over a collection how to determine the current objects index, click here. NAML <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instant...>

--- Regards, Sanjay

------------------------------------------------------------------------ View this message in context: Re: when iterating over a collection how to determine the current objects index <http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the-...>

Sent from the Pharo Smalltalk Users mailing list archive <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at Nabble.com <http://nabble.com/>.

Marcus Denker-4 wrote

which version do we pick? We should pick one, rename the callers

As someone mentioned earlier in the thread, #doWithIndex: has the advantage of mirroring the argument order (although this still should be documented), and it's the one most people are probably most familiar with, so IMHO it makes sense to standardize on that. ----- Cheers, Sean -- View this message in context: http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the-... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Nicolai, Am 16.03.15 um 11:59 schrieb Nicolai Hess:

2015-03-14 11:55 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>>:

Marcus Denker-4 wrote > which version do we pick? We should pick one, rename the callers

As someone mentioned earlier in the thread, #doWithIndex: has the advantage of mirroring the argument order (although this still should be documented), and it's the one most people are probably most familiar with, so IMHO it makes sense to standardize on that.

I like withIndexDo: because code like

so how would you name the current #do: if you had the choice? I still think this looks very logical: #do: #do:separatedBy: #doWithIndex: #doWithSomeOtherSpecialty:andEvenMoreStuff: And then there still ist the question if the order of the arguments should be changed: today: do: [:each| ] doWithIndex: [:each :index| ] future: do: [:each| ] withIndexDo: [:idx :each | ] Do you really think that is better? I think that if we move the withIndex part to the beginning of the message, it overstates the importance of the fact that we also need the index inside the iteration block.

aCollection withIndexDo: aBlock reads like "a collection with index" do

This would make sense if it was a Collection with an Index. If there was an IndexedCollection class and maybe some message like asIndexedCollection or withIndex, which turns any collection into an IndexedCollection. Then the message might be a shortcut for "make thsi an indexed collection and iterate over it using its index" - comparable to Dictionary>>#keysAndValuesDo: - but please be aware that a Dictionary has keys and values by its very own nature. A Collection doesn't have an index (other than the fact that the elements are stored in some non-guarantueed order). This may all sound quite picky, but I think this is plain wrong and you are about to introduce not only incompatible, but also misleading naming for methods that exist on all Smalltalk dialects. Joachim

----- Cheers, Sean -- View this message in context: http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the-... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

so may be we should open a bug entry and make sure that doWithIndex: is used in the system. no? Le 16/3/15 12:19, jtuchel@objektfabrik.de a écrit :

Nicolai,

Am 16.03.15 um 11:59 schrieb Nicolai Hess:

...

2015-03-14 11:55 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>>:

Marcus Denker-4 wrote > which version do we pick? We should pick one, rename the callers

As someone mentioned earlier in the thread, #doWithIndex: has the advantage of mirroring the argument order (although this still should be documented), and it's the one most people are probably most familiar with, so IMHO it makes sense to standardize on that.

I like withIndexDo: because code like

so how would you name the current #do: if you had the choice?

I still think this looks very logical:

#do: #do:separatedBy: #doWithIndex: #doWithSomeOtherSpecialty:andEvenMoreStuff:

And then there still ist the question if the order of the arguments should be changed:

today:

do: [:each| ] doWithIndex: [:each :index| ]

future:

do: [:each| ] withIndexDo: [:idx :each | ]

Do you really think that is better?

I think that if we move the withIndex part to the beginning of the message, it overstates the importance of the fact that we also need the index inside the iteration block.

...

aCollection withIndexDo: aBlock reads like "a collection with index" do

This would make sense if it was a Collection with an Index. If there was an IndexedCollection class and maybe some message like asIndexedCollection or withIndex, which turns any collection into an IndexedCollection. Then the message might be a shortcut for "make thsi an indexed collection and iterate over it using its index" - comparable to Dictionary>>#keysAndValuesDo: - but please be aware that a Dictionary has keys and values by its very own nature. A Collection doesn't have an index (other than the fact that the elements are stored in some non-guarantueed order).

This may all sound quite picky, but I think this is plain wrong and you are about to introduce not only incompatible, but also misleading naming for methods that exist on all Smalltalk dialects.

Joachim

...

----- Cheers, Sean -- View this message in context: http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the-... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchelmailto:jtuchel@objektfabrik.de Fliederweg 1http://www.objektfabrik.de D-71640 Ludwigsburghttp://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

e.g. someObject mongoDo: [ ... ].

withIndexDo: obeys the principle of least astonishment to me.

Except the difference between this case and the other examples is that "withIndex + Do:" reverses the argument order (:e :i). But more importantly, GNU and other Smalltalks have #doWithIndex:. I don’t think that the payoff here is enough to diverge from the rest of the world. Lastly, apparently e.g. Dolphin has removed it completely in favor of #keysAndValuesDo: in response to a change in the ANSI standard. From http://forum.world.st/doWithIndex-tp3374968p3374975.html :

#doWithIndex: was in an early ANSI draft, presumably proposed by one of IBM's representatives but I can't really remember, and we had it in the version of Dolphin current at the time. Later it was removed from the standard and replaced with #keysAndValuesDo:, which makes sense since a sequenced collection can legimitately represent a "keyed collection" with integer keys. Therefore there is no need for a second enumerator that does the same thing but with key and value reversed.

----- Cheers, Sean -- View this message in context: http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the-... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Actually, using keysAndValuesDo: makes a lot of sense to me and seems to be a nice and clean way to resolve this discussion. I really like that it’s nicely polymorphic if we consider the keys of a sequenced collection to be the indexes. I just like this kind of simplicity …

On Mar 18, 2015, at 18:55, Sean P. DeNigris <sean@clipperadams.com> wrote:

Lastly, apparently e.g. Dolphin has removed it completely in favor of #keysAndValuesDo: in response to a change in the ANSI standard. From http://forum.world.st/doWithIndex-tp3374968p3374975.html <http://forum.world.st/doWithIndex-tp3374968p3374975.html> :

...

#doWithIndex: was in an early ANSI draft, presumably proposed by one of IBM's representatives but I can't really remember, and we had it in the version of Dolphin current at the time. Later it was removed from the standard and replaced with #keysAndValuesDo:, which makes sense since a sequenced collection can legimitately represent a "keyed collection" with integer keys. Therefore there is no need for a second enumerator that does the same thing but with key and value reversed.

---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

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. It would be interesting if something like autocompletion could supply the template for the block.

I'm always looking for senders with that type of code ;) arguments to blocks are usually not documented.

I do too. cheers -ben

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