March 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] when iterating over a collection how to determine the current objects index

by Thierry Goubier

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 <i.uhnak(a)gmail.com>: > On Tue, Mar 10, 2015 at 1:23 PM, Joachim Tuchel <jtuchel(a)objektfabrik.de> > wrote: > >> #doWithIndex: ? >> > > doWithIndex: elementAndIndexBlock > "Use the new version with consistent naming" > ^ self withIndexDo: elementAndIndexBlock >

March 10, 2015

Re: [Pharo-users] when iterating over a collection how to determine the current objects index

by Sanjay Minni

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.

March 10, 2015

Re: [Pharo-users] Dealing with multiple cases of a string while keeping code short and OOP friendly

by kilon alios

I have seen a similar pattern in Kent Beck book Smalltalk Patterns , but I was not sure this was a good way to go in this case . So I thought that would not hurt to ask for a second opinion from a more experienced Pharo coder. On Tue, Mar 10, 2015 at 12:03 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > kilon.alios wrote > > oh Sean this so beautiful and elegant > > class := self subclasses detect: [ :c | c pythonClassName = > > pythonClassName > > Yes I like/use this pattern a lot! I think I learned it from "A Mentoring > Course on Smalltalk" > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Dealing-with-multiple-cases-of-a-string-while-keeping… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

March 10, 2015

Re: [Pharo-users] when iterating over a collection how to determine the current objects index

by Peter UhnÃ¡k

On Tue, Mar 10, 2015 at 1:23 PM, Joachim Tuchel <jtuchel(a)objektfabrik.de> wrote: > #doWithIndex: ? > doWithIndex: elementAndIndexBlock "Use the new version with consistent naming" ^ self withIndexDo: elementAndIndexBlock

March 10, 2015

Re: [Pharo-users] when iterating over a collection how to determine the current objects index

by Joachim Tuchel

#doWithIndex: ? > Am 10.03.2015 um 13:11 schrieb Sanjay Minni <sm(a)planage.com>: > > Hi > > when iterating over a sequenced collection (array / ordered collection) how > can I determine the current objects index value (without explicitly storing > a counter or looking to match each time) > > Typically I need it: > 1. to display a serial number when printing a report. > 2. to determine if I am on the last element. > 3. To highlight every n-th element. > > 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. > >

March 10, 2015

when iterating over a collection how to determine the current objects index

by Sanjay Minni

Hi when iterating over a sequenced collection (array / ordered collection) how can I determine the current objects index value (without explicitly storing a counter or looking to match each time) Typically I need it: 1. to display a serial number when printing a report. 2. to determine if I am on the last element. 3. To highlight every n-th element. 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.

March 10, 2015

Re: [Pharo-users] smaller configurations vs groups [was Re: Pillar and GT tools in Pharo4]

by stepharo

I agree!!!!!!!! Stef Le 8/3/15 13:24, Tudor Girba a Ã©crit : > Hi, > > I summarize below why I think fine grained configurations should be > preferred to groups. > > The group is not a first class configuration, although it can be > depended on. If you depend on a group of a configuration, it's harder > to understand the consequences and it's harder to build tools for it. > > Consider the graph below representing the dependencies starting from > ConfigurationOfMoose #development: > Inline image 2 > > It's a simple representation of dependencies, and it makes the maze of > configurations easier to grasp. The interesting thing about it is that > by showing a configuration node only once, you can see how multiple > other projects depend on it. For example, HashTable is being depended > on by two distinct configurations. > > You can also see that Magritte depends on Grease, but you do not see > that it only depends on the Core group. To do that, you have to look > at the details of the edge. > > We used to have groups in GT, however, after a while we moved to more > fine grained configurations. As a consequence, you can see that > GlamourCore (which used to be a group in Glamour) is being depended on > by three different configurations. Using first class configurations > makes tool building (like representation, navigation or release) easier. > > You could argue that we could represent a Group as node, however, even > then you would not be able to see dependencies between groups that > reside within the same configuration because groups are not first > class configurations that can explicitly define dependencies, they are > just groups. > > Groups might provide an apparent ease of use for quick things, but I > strongly believe that they are an unessential construct and that if we > would not use them, tools would become cheaper and more effective. > > Cheers, > Doru > > > > > On Sun, Mar 8, 2015 at 1:14 AM, Damien Cassou <damien.cassou(a)gmail.com > <mailto:damien.cassou@gmail.com>> wrote: > > > On Mar 7, 2015 4:42 AM, "Tudor Girba" <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>> wrote: > > > > Actually, I would rather prefer to create a separate > ConfigurationOfPillarTools that adds the Pillar-Pharo-Tools and > the PetitParser dependency. What that be Ok? > > Ok for me, do as you prefer. What is your rationale? > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

March 10, 2015

Re: [Pharo-users] Why `aFileReference asString = aFileReference fullName` is false?

by Esteban A. Maringolo

2015-03-10 8:43 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Sorry, but the mechanism is one thing, the semantics another. Calling it displayString won't solve the problem. > > The problem is that there is often more than one useful string representation. That's why I said it is a matter of taste. In the end, not having a concrete #asString implementation might be a good choice. Esteban A. Maringolo

March 10, 2015

Re: [Pharo-users] new link to query all projects in smalltalkhub

by Nicolai Hess

2015-03-10 11:50 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Hi, > You can now look at > > http://smalltalkhub.com/projectList > > to query all public smalltalkhub projects. > Great! > is an âold styleâ web pageâ¦ so do not expect too muchâ¦ but at least you > can see what is around :) > > enjoy, > Esteban >

March 10, 2015

Re: [Pharo-users] Why `aFileReference asString = aFileReference fullName` is false?

by Sven Van Caekenberghe

Sorry, but the mechanism is one thing, the semantics another. Calling it displayString won't solve the problem. The problem is that there is often more than one useful string representation. Like for the example at hand. (FileLocator desktop / 'foo.txt') resolve. Has the following #printString File @ /Users/sven/Desktop/foo.txt OK, both of the following make sense /Users/sven/Desktop/foo.txt file:///Users/sven/Desktop/foo.txt But what about native (OS platform) conventions ? I don't want to see Windows backslashes, but Windows user might disagree. There is not one good solution, hence you must use specific accessors/convertors. > On 10 Mar 2015, at 12:20, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > > El mar 10, 2015 8:13 AM, "Sean P. DeNigris" <sean(a)clipperadams.com> escribiÃ³: > > > > Ben Coman wrote > > > Now the followup question is whether its natural to expect something > > > better from #asString > > > > I feel like #asString is such a general question that no answer would be > > satisfying. What string representation should be returned? 'file://'? > > '/path/to'? And what to do with memory file systems? It's been mentioned a > > few times on the list that we should all be more disciplined in sending e.g. > > #displayString vs. #printString instead of #asString. The more I hear that > > argument, the more sense it makes to me. > > I would remove #asString and use #displayString everywhere. But it should be implemented in Object, based on a #displayOn: method just like printString does. > > If a method starts with #as... I read "I will cast this object into something else". Which will be subject to taste. > > Regarding this particular case I would implement #asString as a delegation to the method that returns '/foo/bar/baz'. An URL's #asString would return 'file:///foo/bar/baz'. > > Regards!

March 10, 2015