September 2019 - Pharo-users

Re: [Pharo-users] My Pharo Wiki

by Julien

Hello Sean, Nice work. :-) Do you know about pharo-open-documentation/pharo-wiki [1] ? With Cyril and Oleks, we started it to collect code snippets. Now that it gows bigger and people start to contribute, we try to build a real wiki to document obscure features of Pharo. Tell us if you want to contribute, we would be happy of any help! :-) Cheers, Julien Links: [1]: https://github.com/pharo-open-documentation/pharo-wiki <https://github.com/pharo-open-documentation/pharo-wiki> --- Julien Delplanque Doctorant Ã lâUniversitÃ© de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > Le 9 sept. 2019 Ã 20:18, Sean P. DeNigris <sean(a)clipperadams.com> a Ã©crit : > > I've been collecting Pharo tidbits that I found interesting for quite a > while. I was aggregating everything today and realized that it had grown > into a small "cookbook" which has some useful information not otherwise > easily available. I share it in case it is of help: > > https://github.com/seandenigris/pharo/wiki > > NB it was written for my personal use so it may be rough around the edges. > Feel free to ask questions if I can clarify anything. > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Sept. 9, 2019

My Pharo Wiki

by Sean P. DeNigris

I've been collecting Pharo tidbits that I found interesting for quite a while. I was aggregating everything today and realized that it had grown into a small "cookbook" which has some useful information not otherwise easily available. I share it in case it is of help: https://github.com/seandenigris/pharo/wiki NB it was written for my personal use so it may be rough around the edges. Feel free to ask questions if I can clarify anything. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 9, 2019

Re: [Pharo-users] uFFI Structure Problem

by Georg Hagn

Thank you Esteban for your fast answer. 1) NULL Pointer assignment: I have implemented your advise, and changed the attribute "abrufCode" to "ExternalAddress null"; >> fieldDesc #(myStruct uint32 version; ... void * abrufCode; ) The Structure has a NULL pointer assigned!? (see Inspector on MyStruct "MyStruct ( version: 2 zertifikatHandle: (void*)@ 16r7F8400000001 pin: (char*)@ 16r7F84FB7FE5A0 abrufCode: (void*)@ 16r00000000 )" But the problem is the same. I get the error: "attribute abrufCode must have the value NULL." Any ideas? 2) coercing problem: In my various tries I changed the whole structure to ExternalAddress null. (In some circumstances I have to set the whole Structure to NULL) Now I got an coercing error. I think, because ExternalAddress is not a FFIExternalStructure. " ^ self ffiCall: #(int BearbeiteVorgang(String daten, String version, int flags, ExternalAddress * druck, MyStruct * crypto, TransferHandle * transfer, RueckgabeHandle * rueckgabe, RueckgabeHandle * serverantwort)). " Is it possible, NOT to decide between (here 4: druck and crypto can be either Structures or NULL) ffi-calls? Thank you, Georg Am Do., 5. Sept. 2019 um 16:30 Uhr schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > > > On 5 Sep 2019, at 17:41, Georg Hagn <georg.hagn(a)gmail.com> wrote: > > I have to implemet following external structure (extrakt from the > german api Doku): > > typedef struct { > /**@brief MUST be always 2. */ > uint32_t version; > > /** @brief Pointer to KeyStore -- Verweis auf den KeyStore, see > EricGetHandleToCertificate(). */ > EricZertifikatHandle zertifikatHandle; > > /** @brief PIN fÃ¼r den KeyStore.*/ > const char *pin; > > /** > * @brief MUST be NULL in my context > Dieser muss ... > In allen anderen FÃ¤llen muss hier NULL Ã¼bergeben > werden. Der Parameter abrufCode > besteht aus 2 x 5 Zeichen, die mit "-" verbunden sind. > Beispiel: "K6FG5-RS32P" > */ > const char *abrufCode; > > } eric_verschluesselungs_parameter_t; > > My Problem is, that i have to assign a NULL - value to the attribute abrufCode. > I have tried varies possibilities but I get always the error, that the > attribute abrufCode must have the value NULL. > > " Extract from log-file: > 019-09-05 17:08:52,257709[0x00007fe036a2f050] ERROR: FÃ¼r die > Ã¼bermittelte Datenart ist die Angabe eines Abrufcodes nicht zulÃ¤ssig, > daher muss fÃ¼r den Abrufcode der Wert NULL Ã¼bergeben werden. > 610001029" > > How do I assign a NULL value to an attribute in a FFIExternalStructure? > > > The problem is not that is an structure but that is a char *, which is converted to a String in Pharo. > Ideally, a nil should be mapped to NULL in this cases, but this is not working (never implemented). > > Easiest workaround, just map abrufCode to void * instead char * (pointers are always same size). > > So you can have: > > myStryct abrufCode: ExternalAddress null. > > But of course, that will change the way you put the value there when *it is not* a NULL: > > myStryct abrufCode: âhelloâ utf8Encoded copyWith 0. > > (The copyWith: 0 is to ensure the void * will receive something with proper \0 finalisation) > > Esteban > > > Following my last attempt (extracted from the Pharo Booklet Colletion > "Calling Foreign Functions with Pharo May 31,2018") > I assign values not directly with the generated attributes but with > "api???" attributes. > > FFIExternalStructure subclass: #ERiCVerschluesselungsParameter > instanceVariableNames: '' > classVariableNames: 'OFFSET_ABRUFCODE OFFSET_PIN OFFSET_VERSION > OFFSET_ZERTIFIKATHANDLE' > package: 'Bajoras-ERiC'! > > > ERiCVerschluesselungsParameter class >> fieldsDesc [ > > "ERiCVerschluesselungsParameter rebuildFieldAccessors" > > ^ #( > uint32 version; > ERiCZertifikatHandle * zertifikatHandle; > char * pin; > char * abrufCode; > ) > ] > > ERiCVerschluesselungsParameter >> initialize [ > > self > apiVersion: 2; > apiAbrufCode: nil; > apiPin: 'mySecret'. > ] > > ERiCVerschluesselungsParameter >> accessorMethods for: pin, version, > abrufCode, zertifikatHandle ("This method were automatically > generated") > > ERiCVerschluesselungsParameter >> apiAbrufCode: aCode [ > > | codeSize anAbrufCode | > > codeSize := 11. > anAbrufCode := FFIExternalArray externalNewType: 'char' size: codeSize. > 1 to: codeSize do: [ :idx | anAbrufCode at: idx put: Character null ] . > > aCode ifNotNil: [ > aCode doWithIndex: [ :char :i | anAbrufCode at: i put: char ]. > ]. > > self abrufCode: anAbrufCode. > > ] > > ERiCVerschluesselungsParameter >> apiPin: aPin [ > > | newPin | > > newPin := FFIExternalArray externalNewType: 'char' size: aPin size. > aPin doWithIndex: [ :char :i | newPin at: i put: char ]. > > self pin: newPin. > ] > > > ERiCVerschluesselungsParameter >> apiVersion: aVersion [ > > | cryptoVersion | > > cryptoVersion := 2. > self version: cryptoVersion. > > ] > > Thanks, > Georg Hagn > >

Sept. 9, 2019

Re: [Pharo-users] Set >> collect:thenDo:

by Steffen MÃ¤rcker

I think this thread indicates that the selector #collect:thenDo: may indeed cause some missunderstanding given standard semantics of #collect:. Is there any reason not to use a different one, such as #map:thenDo:, to make the difference clearer? A nice side effect could be a new automatic refactoring rule that consolidates chained #collect: and #do: sends into a faster #collect:thenDo: send without breaking existing code. Am .09.2019, 07:46 Uhr, schrieb Richard O'Keefe <raoknz(a)gmail.com>: > (1) If you want (aSet collect: collectBlock) do: doBlock > you can write exactly that. Nothing stops you, and it will > be as clear and reliable as any use of Set>>collect:, which > is to say NOT VERY CLEAR OR RELIABLE AT ALL. > > (2) #collect:then{Do:Select:Reject:} had no other purpose than > to avoid creating an intermediate and otherwise useless > collection. If you are not trying to involve an intermediate > set then it just plain wrong to use #collect:thenDo:. > > (3) Oddly enough, the reason that #collect:thenDo: exists in my > library is that I copied it from Squeak, at a time when it had > the same definition as Pharo and ST/X. Had I known of the change > in Squeak I would have bitterly opposed it. The comment in the > current Squeak code, that it is for readability, is 100% the > reverse of the truth. Using the version with parentheses is WAY > clearer than using the portmanteau method. Sigh. I see they > broke #collect:thenSelect: in the same way. > > (4) Let me offer you another member of the #collect:then* family. > > Collection > collect: collectBlock thenInject: initial into: injectBlock > |r| > r := initial. > self do: [:each | > r := injectBlock value: r value: (collectBlock value: each)]. > ^r > > #(now is the hour for us to say goodbye) asSet > collect: [:each | each size] > thenInject: 0 into: [:acc :each | acc + each] > => 29 > (#(now is the hour for us to say goodbye) asSet > collect: [:each | each size]) > inject: 0 into: [:acc :each | acc + each] > => 16 > > That is, it would be WRONG to implement #collect:thenInject:into: > as #collect: followed by #inject:into:. The point is NOT to > coalesce things that the receiver might (in general, incorrectly) > regard as equal. > > (5) The bottom line is that if #collect:thenDo: and its relatives did > not have their present semantics in Pharo (and ST/X), they would > need to be reinvented, with names that were not as clear. > > (1) Just to repeat for emphasis, if you *want* (_ collect: _) do: _ > then that is exactly what you should write. There is no > excuse for using #collect:thenDo: in that case. It is NOT > clearer to do so. And you should imagine me jumping up and > down screaming that sending #collect: to a set is a bad code > smell which demands very explicit documentation as to why you > (for example) want a Set to answer a Set but an IdentitySet > to also answer a Set, not the expected IdentitySet. (I have > been bitten by that more than once.) > > > > On Mon, 9 Sep 2019 at 01:33, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > >> On 8. 9. 2019 14:28, Peter Kenny wrote: >> > Two comments: >> > First, the method comment for Collection>>collect:thenDo: is "Utility >> method >> > to improve readability", which is exactly the same as for >> > collect:thenSelect: and collect:thenReject:. This suggests that the >> > *intention* of the method is not to introduce new behaviour, but >> simply >> to >> > provide a shorthand for the version with parentheses. For other kinds >> of >> >> I had that same impression. >> >> > collection this is true; just the deduping makes Set different. If we >> want >> >> I would be more defensive here and say that generic collection should >> have (collect:)do: implementation and only sequenceable collections have >> the optimized one (if it indeed is the case that it is a shotrhand for >> parenthesized one). >> >> > the different behaviour, this should be indicated by method name and >> > comment. >> > Second, if we remove asSet from the second snippet, the output is >> exactly >> > the same. It will be the same as long as the original collection has >> no >> > duplicates. Somehow the effect is to ignore the asSet. It just smells >> wrong. >> > >> > Peter Kenny >> >> Herby >> >> > Kasper Osterbye wrote >> >> The first version: >> >> >> >> (#(1 2 3) asSet collect: #odd) >> >> do: [ :each | Transcript show: each; cr ] >> >> >> >> is rather straight forward I believe, as collect: and do: has been >> around >> >> forever (relatively speaking). >> >> >> >> >> >> #(1 2 3) asSet collect: #odd >> >> thenDo: [ :each | Transcript show: each; cr ] >> >> >> >> >> >> On 8 September 2019 at 09.13.36, Richard Sargent ( >> > >> >> richard.sargent@ >> > >> >> ) wrote: >> >> >> >> I am skeptical of one that relies on a specific implementation >> rather >> >> than >> >> a specific definition. >> >> >> >> I share your feeling. I am not sure where such a definition would >> come >> >> from. In Squeak it is defined as: >> >> >> >> collect: collectBlock thenDo: doBlock >> >> >> >> ^ (self collect: collectBlock) do: doBlock >> >> >> >> In pharo as: >> >> >> >> collect: collectBlock thenDo: doBlock >> >> >> >> ^ self do: [ :each | doBlock value: (collectBlock value: each)] >> >> >> >> I might have called the method collect:eachDo:, but we each have >> slightly >> >> different styles. What I like about the pharo version is that is a >> >> shorthand for something which is not achieved by mere parentheses. >> >> >> >> Best, >> >> >> >> Kasper >> > >> > >> > >> > >> > >> > -- >> > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> > >> >> >>

Sept. 9, 2019

Re: [Pharo-users] Set >> collect:thenDo:

by David T. Lewis

On Mon, Sep 09, 2019 at 05:46:48PM +1200, Richard O'Keefe wrote: > > (3) Oddly enough, the reason that #collect:thenDo: exists in my > library is that I copied it from Squeak, at a time when it had > the same definition as Pharo and ST/X. Had I known of the change > in Squeak I would have bitterly opposed it. The comment in the > current Squeak code, that it is for readability, is 100% the > reverse of the truth. Using the version with parentheses is WAY > clearer than using the portmanteau method. Sigh. I see they > broke #collect:thenSelect: in the same way. > In Squeak, collect:thenDo: is implemented only in Collection. The method stamp is dgd 9/13/2004 23:42, which hardly qualifies as a recent change. And the method stamp for collect:thenSelect: is sma 5/12/2000. Dave

Sept. 9, 2019

Re: [Pharo-users] Set >> collect:thenDo:

by Richard O'Keefe

(1) If you want (aSet collect: collectBlock) do: doBlock you can write exactly that. Nothing stops you, and it will be as clear and reliable as any use of Set>>collect:, which is to say NOT VERY CLEAR OR RELIABLE AT ALL. (2) #collect:then{Do:Select:Reject:} had no other purpose than to avoid creating an intermediate and otherwise useless collection. If you are not trying to involve an intermediate set then it just plain wrong to use #collect:thenDo:. (3) Oddly enough, the reason that #collect:thenDo: exists in my library is that I copied it from Squeak, at a time when it had the same definition as Pharo and ST/X. Had I known of the change in Squeak I would have bitterly opposed it. The comment in the current Squeak code, that it is for readability, is 100% the reverse of the truth. Using the version with parentheses is WAY clearer than using the portmanteau method. Sigh. I see they broke #collect:thenSelect: in the same way. (4) Let me offer you another member of the #collect:then* family. Collection collect: collectBlock thenInject: initial into: injectBlock |r| r := initial. self do: [:each | r := injectBlock value: r value: (collectBlock value: each)]. ^r #(now is the hour for us to say goodbye) asSet collect: [:each | each size] thenInject: 0 into: [:acc :each | acc + each] => 29 (#(now is the hour for us to say goodbye) asSet collect: [:each | each size]) inject: 0 into: [:acc :each | acc + each] => 16 That is, it would be WRONG to implement #collect:thenInject:into: as #collect: followed by #inject:into:. The point is NOT to coalesce things that the receiver might (in general, incorrectly) regard as equal. (5) The bottom line is that if #collect:thenDo: and its relatives did not have their present semantics in Pharo (and ST/X), they would need to be reinvented, with names that were not as clear. (1) Just to repeat for emphasis, if you *want* (_ collect: _) do: _ then that is exactly what you should write. There is no excuse for using #collect:thenDo: in that case. It is NOT clearer to do so. And you should imagine me jumping up and down screaming that sending #collect: to a set is a bad code smell which demands very explicit documentation as to why you (for example) want a Set to answer a Set but an IdentitySet to also answer a Set, not the expected IdentitySet. (I have been bitten by that more than once.) On Mon, 9 Sep 2019 at 01:33, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > On 8. 9. 2019 14:28, Peter Kenny wrote: > > Two comments: > > First, the method comment for Collection>>collect:thenDo: is "Utility > method > > to improve readability", which is exactly the same as for > > collect:thenSelect: and collect:thenReject:. This suggests that the > > *intention* of the method is not to introduce new behaviour, but simply > to > > provide a shorthand for the version with parentheses. For other kinds of > > I had that same impression. > > > collection this is true; just the deduping makes Set different. If we > want > > I would be more defensive here and say that generic collection should > have (collect:)do: implementation and only sequenceable collections have > the optimized one (if it indeed is the case that it is a shotrhand for > parenthesized one). > > > the different behaviour, this should be indicated by method name and > > comment. > > Second, if we remove asSet from the second snippet, the output is exactly > > the same. It will be the same as long as the original collection has no > > duplicates. Somehow the effect is to ignore the asSet. It just smells > wrong. > > > > Peter Kenny > > Herby > > > Kasper Osterbye wrote > >> The first version: > >> > >> (#(1 2 3) asSet collect: #odd) > >> do: [ :each | Transcript show: each; cr ] > >> > >> is rather straight forward I believe, as collect: and do: has been > around > >> forever (relatively speaking). > >> > >> > >> #(1 2 3) asSet collect: #odd > >> thenDo: [ :each | Transcript show: each; cr ] > >> > >> > >> On 8 September 2019 at 09.13.36, Richard Sargent ( > > > >> richard.sargent@ > > > >> ) wrote: > >> > >> I am skeptical of one that relies on a specific implementation rather > >> than > >> a specific definition. > >> > >> I share your feeling. I am not sure where such a definition would come > >> from. In Squeak it is defined as: > >> > >> collect: collectBlock thenDo: doBlock > >> > >> ^ (self collect: collectBlock) do: doBlock > >> > >> In pharo as: > >> > >> collect: collectBlock thenDo: doBlock > >> > >> ^ self do: [ :each | doBlock value: (collectBlock value: each)] > >> > >> I might have called the method collect:eachDo:, but we each have > slightly > >> different styles. What I like about the pharo version is that is a > >> shorthand for something which is not achieved by mere parentheses. > >> > >> Best, > >> > >> Kasper > > > > > > > > > > > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > > > >

Sept. 9, 2019

Re: [Pharo-users] Set >> collect:thenDo:

by Richard O'Keefe

The difference in behaviour is exactly what I would expect. I can't think of any way to make aSet collect: collectBlock thenDo: doBlock act identically to (aSet collect: collectBlock) do: doBlock without creating an intermediate set. Here, for example, is the definition in Smalltalk/X, with comments removed for brevity. collect:collectBlock thenDo:aBlock self do:[:each | aBlock value:(collectBlock value:each)]. (The lack of spaces after keywords is ST/X convention.) Another way to express this would be with a function composition combinator: aSet do: (collectBlock before: doBlock). aSet do: (doBlock after: collectBlock). Note, by the way, that Set>>collect: has always been something to approach with vigilant trepidation. Given Set, IdentitySet, and PluggableSet, there is in general no reason to expect that the receiver's notion of equality is approach for the results of the collectBlock. That's why my library lets me write Set withAll: collection collect: collectBlock IdentitySet withAll: collection collect: collectBlock (PluggableSet equalBy: equality hashBy: hasher) withAll: collection collect: collectBlock (PluggableSet accordingTo: equivalence) withAll: collection collect: collectBlock So in the case of aSet collect: collectBlock thenDo: doBlock there is no reason to expect aSet to know how to tell when two collectBlock results should be regarded as equivalent. Seriously, how is aSet supposed to know what collectBlock thinks equivalence looks like? On Sun, 8 Sep 2019 at 03:22, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > Hello! > > ---- > (#(1 2 3) asSet collect: #odd) > do: [ :each | Transcript show: each; cr ] > > > true > > false > > ---- > > #(1 2 3) asSet collect: #odd > thenDo: [ :each | Transcript show: each; cr ] > > > true > > false > > true > ---- > > > Bug or feature? > > Herby > >

Sept. 9, 2019

Re: [Pharo-users] Best Practices for Adapting JSON based APIs

by Paul DeBruicker

Hi - 1. There is a Stripe package here: http://smalltalkhub.com/#!/~pdebruic/Stripe MCHttpRepository location: 'http://smalltalkhub.com/mc/pdebruic/Stripe/main' user: '' password: '' You can see how it adapts to Stripe's changing API spec. 2. NeoJSONObject, which is part of Svens' NeoJSON package & JsonObject of the JSON package here: http://smalltalkhub.com/#!/~PharoExtras/JSON each overrides #doesNotUnderstand: to return nil when you send messages the JSON object doesn't define. E.g. given JSON of {a: 1, b: 2} you can myJson:=Json readFrom: '{"a": 1, "b":2}' readStream myJson a. "1" myJson b: 25. "sets b to 25" myJson b. "25" myJson zebra. "nil" I like and use both the JSON packages but don't like using the overriden #dnu mechanism because you cannot track implementors. So later when you want to know what #zebra does you cannot see it and have to remember its a JSON object and you're doing a dictionary lookup. But its a flexible way to deal with JSON objects sith varying fields. 3. Yes. Because I want to be able to see implementors. 4. No, not from an arbitrary spec. Google publishes some of their APIs as JSON specs and there is a project to interpret those specs and automatically build objects and interfaces here https://github.com/seandenigris/St-Google-API If there is a standard way to define APIs (swagger maybe? I'm not sure) then you could make something that does what you want for that API spec spec. Hope this helps darth-cheney wrote > Hello all, > > Several times in the past couple of years I've found myself attempting to > create objects that incorporate/adapt a given APIs specification -- in > other words, building a mini, pharo based SDK for the given API. These are > always JSON based APIs. > > I am not sure what the best practices are for doing this and am looking > for > some wisdom from this list. I have a few questions: > > 1. When passing around JSON-based objects for a given API, is it better to > work with Dictionaries or to create (for example) specific objects for > specific kinds of JSON objects in the API -- ie for Stripe, would you just > work with objects that read and parse Dictionaries or implement > Transaction, User, CreditCard objects, etc, etc? > > 2. If you create objects for each kind of entity rather than using > dictionaries, what do you do in the (rather common) case where the API > specification allows for a lot of malleability in a given JSON object that > gets passed in for a given kind of request? Often times there can be > arbitrary, non-required key-value pairs set by the user for a given > transaction/request/whatever on the JSON object. I'm not sure how this > would translate to Pharo objects, especially if we are creating a > method-per-key > 3. Do you create a method per what would be a key in the spec's JSON > object? > 4. If a given API spec is itself written in JSON, do we have some way of > "automatically" creating the equivalent objects in Pharo (since both are > machine readable)? > > I am currently considering developing a bare-bones proof of concept > package > for making a Matrix Client <https://matrix.org/docs/spec> but I'm a > bit > flummoxed about how to proceed, since there seem to be many ways to do > this > -- some that might be worse than others for testing, abstraction, etc, > etc. > > Any advice is much appreciated. Thanks! > > -- , > Eric -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 8, 2019

Best Practices for Adapting JSON based APIs

by Eric Gade

Hello all, Several times in the past couple of years I've found myself attempting to create objects that incorporate/adapt a given APIs specification -- in other words, building a mini, pharo based SDK for the given API. These are always JSON based APIs. I am not sure what the best practices are for doing this and am looking for some wisdom from this list. I have a few questions: 1. When passing around JSON-based objects for a given API, is it better to work with Dictionaries or to create (for example) specific objects for specific kinds of JSON objects in the API -- ie for Stripe, would you just work with objects that read and parse Dictionaries or implement Transaction, User, CreditCard objects, etc, etc? 2. If you create objects for each kind of entity rather than using dictionaries, what do you do in the (rather common) case where the API specification allows for a lot of malleability in a given JSON object that gets passed in for a given kind of request? Often times there can be arbitrary, non-required key-value pairs set by the user for a given transaction/request/whatever on the JSON object. I'm not sure how this would translate to Pharo objects, especially if we are creating a method-per-key 3. Do you create a method per what would be a key in the spec's JSON object? 4. If a given API spec is itself written in JSON, do we have some way of "automatically" creating the equivalent objects in Pharo (since both are machine readable)? I am currently considering developing a bare-bones proof of concept package for making a Matrix Client <https://matrix.org/docs/spec> but I'm a bit flummoxed about how to proceed, since there seem to be many ways to do this -- some that might be worse than others for testing, abstraction, etc, etc. Any advice is much appreciated. Thanks! -- , Eric

Sept. 8, 2019

Re: [Pharo-users] Set >> collect:thenDo:

by Herby VojÄÃk

On 8. 9. 2019 14:28, Peter Kenny wrote: > Two comments: > First, the method comment for Collection>>collect:thenDo: is "Utility method > to improve readability", which is exactly the same as for > collect:thenSelect: and collect:thenReject:. This suggests that the > *intention* of the method is not to introduce new behaviour, but simply to > provide a shorthand for the version with parentheses. For other kinds of I had that same impression. > collection this is true; just the deduping makes Set different. If we want I would be more defensive here and say that generic collection should have (collect:)do: implementation and only sequenceable collections have the optimized one (if it indeed is the case that it is a shotrhand for parenthesized one). > the different behaviour, this should be indicated by method name and > comment. > Second, if we remove asSet from the second snippet, the output is exactly > the same. It will be the same as long as the original collection has no > duplicates. Somehow the effect is to ignore the asSet. It just smells wrong. > > Peter Kenny Herby > Kasper Osterbye wrote >> The first version: >> >> (#(1 2 3) asSet collect: #odd) >> do: [ :each | Transcript show: each; cr ] >> >> is rather straight forward I believe, as collect: and do: has been around >> forever (relatively speaking). >> >> >> #(1 2 3) asSet collect: #odd >> thenDo: [ :each | Transcript show: each; cr ] >> >> >> On 8 September 2019 at 09.13.36, Richard Sargent ( > >> richard.sargent@ > >> ) wrote: >> >> I am skeptical of one that relies on a specific implementation rather >> than >> a specific definition. >> >> I share your feeling. I am not sure where such a definition would come >> from. In Squeak it is defined as: >> >> collect: collectBlock thenDo: doBlock >> >> ^ (self collect: collectBlock) do: doBlock >> >> In pharo as: >> >> collect: collectBlock thenDo: doBlock >> >> ^ self do: [ :each | doBlock value: (collectBlock value: each)] >> >> I might have called the method collect:eachDo:, but we each have slightly >> different styles. What I like about the pharo version is that is a >> shorthand for something which is not achieved by mere parentheses. >> >> Best, >> >> Kasper > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Sept. 8, 2019