String operations
Locked
 
|
Hi,
am I really blind, or is there no way to do something like 'BormParticipant' removePrefix: 'Borm' "-> 'Participant'" or 'BormParticipant' copyFrom: 5 "-> 'Participant'" "OrderedCollection knows this" I can do copyFrom:to:, but that requires asking the size of the string, which is (in my eyes) ugly. So is there better (=single message) way? Thanks, Peter |
|
Hello Peter,
Finder can't find when you need to compose two messages, this one does it: ('BormParticipant' splitOn: 'Borm') last Hilaire Le 06/04/2015 12:34, Peter Uhnák a écrit : > Hi, > > am I really blind, or is there no way to do something like > 'BormParticipant' removePrefix: 'Borm' "-> 'Participant'" > or > 'BormParticipant' copyFrom: 5 "-> 'Participant'" "OrderedCollection > knows this" > > I can do copyFrom:to:, but that requires asking the size of the > string, which is (in my eyes) ugly. > > So is there better (=single message) way? > > Thanks, > Peter -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu |
|
|
In reply to this post by Peter Uhnak
If you have the amount auf characters you want to omit you can do
'BormParticipant' allButFirst: 4 Norbert > Am 06.04.2015 um 12:34 schrieb Peter Uhnák <[hidden email]>: > > Hi, > > am I really blind, or is there no way to do something like > 'BormParticipant' removePrefix: 'Borm' "-> 'Participant'" > or > 'BormParticipant' copyFrom: 5 "-> 'Participant'" "OrderedCollection knows this" > > I can do copyFrom:to:, but that requires asking the size of the string, which is (in my eyes) ugly. > > So is there better (=single message) way? > > Thanks, > Peter |
|
|
In the Moose configuration, there is a CollectionExtensions that allows you to do this: 'BormParticipant' removePrefix: 'Borm' "-> 'Participant'". 'BormParticipant' removeSuffix: 'Participant' "-> 'Borm'" For Pharo 5, we should move these extensions to Pharo. Cheers, Doru On Mon, Apr 6, 2015 at 12:51 PM, Norbert Hartl <[hidden email]> wrote: If you have the amount auf characters you want to omit you can do |
|
|
Isn't it the case that a remove* methods mostly return what has been removed? Wouldn't be withoutPrefix: withoutSuffix: a good alternative? my 2 cents, Norbert
|
|
|
'BormParticipant' allButFirst: 4 ('BormParticipant' splitOn: 'Borm') last Thank you both, this will work. :)
I guess withoutPrefix: would probably makes more sense. Thanks, Peter |
|
|
As well as allButPrefix: allButSuffix: but to me the sound of them is weird. Norbert |
|
|
Indeed, there is much to say about the String API :) Thanks for mentioning this, I'm gathering missing behavior like this ! On 8 April 2015 at 17:56, Norbert Hartl <[hidden email]> wrote:
|
|
Administrator
|
It seems unanimous that we should add these. I agree that they are useful in some cases. However, strings are so general that IMHO there are infinite such operations that we could add. Already "String methodDict size = 333", and one can't depend on method protocols to sort things out because they are hijacked for package extensions, so it's easy to be fooled by thinking "let me check the converting protocol for that" and (maybe) finding out later that you missed it because #asXyz is in *OtherPackage, which now forces you to manually scroll through 333 methods to make sure your desired message hasn't been implemented. So I'm not saying "don't add them". I just want to have a conversation about: 1. How often would these be needed? (We should have that conversation about most of String's methods) 2. Do we have any plans for real protocols, with the concepts of privacy and package extension extracted into other objects where they belong? 3. In the mean time, what is a reasonable cognitive limit for an API? For me 333 is way beyond comprehension with the current tooling, crippled somewhat by #2.
Cheers,
Sean |
|
|
On Thu, Apr 9, 2015 at 12:59 PM, Sean P. DeNigris <[hidden email]> wrote: Damien Pollet-2 wrote |
|
|
In reply to this post by Tudor Girba-2
+ 1 :)
can you open a bug entry and I prefer withoutPrefix:, withoutSuffix: Stef Le 6/4/15 21:28, Tudor Girba a écrit :
|
|
|
In reply to this post by Sean P. DeNigris
Hi sean
with damien we are restarting to work on analysing String API. We would like to have it much more regular. We will finish a first small articles summarizing our analysis and send it around. Stef Le 9/4/15 12:59, Sean P. DeNigris a écrit : > Damien Pollet-2 wrote >> Indeed, there is much to say about the String API :) >> Thanks for mentioning this, I'm gathering missing behavior like this ! > It seems unanimous that we should add these. I agree that they are useful in > some cases. However, strings are so general that IMHO there are infinite > such operations that we could add. Already "String methodDict size = 333", > and one can't depend on method protocols to sort things out because they are > hijacked for package extensions, so it's easy to be fooled by thinking "let > me check the converting protocol for that" and (maybe) finding out later > that you missed it because #asXyz is in *OtherPackage, which now forces you > to manually scroll through 333 methods to make sure your desired message > hasn't been implemented. > > So I'm not saying "don't add them". I just want to have a conversation > about: > 1. How often would these be needed? (We should have that conversation about > most of String's methods) > 2. Do we have any plans for real protocols, with the concepts of privacy and > package extension extracted into other objects where they belong? > 3. In the mean time, what is a reasonable cognitive limit for an API? For me > 333 is way beyond comprehension with the current tooling, crippled somewhat > by #2. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/String-operations-tp4817803p4818540.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > |
|
|
In reply to this post by Sean P. DeNigris
+1.
In addition, half the methods you usually look for is actually implemented in their proper place (that is, SequenceableCollection, not String). Cheers, Henry > On 09 Apr 2015, at 12:59 , Sean P. DeNigris <[hidden email]> wrote: > > Damien Pollet-2 wrote >> Indeed, there is much to say about the String API :) >> Thanks for mentioning this, I'm gathering missing behavior like this ! > > It seems unanimous that we should add these. I agree that they are useful in > some cases. However, strings are so general that IMHO there are infinite > such operations that we could add. Already "String methodDict size = 333", > and one can't depend on method protocols to sort things out because they are > hijacked for package extensions, so it's easy to be fooled by thinking "let > me check the converting protocol for that" and (maybe) finding out later > that you missed it because #asXyz is in *OtherPackage, which now forces you > to manually scroll through 333 methods to make sure your desired message > hasn't been implemented. > > So I'm not saying "don't add them". I just want to have a conversation > about: > 1. How often would these be needed? (We should have that conversation about > most of String's methods) > 2. Do we have any plans for real protocols, with the concepts of privacy and > package extension extracted into other objects where they belong? > 3. In the mean time, what is a reasonable cognitive limit for an API? For me > 333 is way beyond comprehension with the current tooling, crippled somewhat > by #2. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/String-operations-tp4817803p4818540.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > |
|
|
In reply to this post by stepharo
Great. I am interested in providing feedback. Doru On Thu, Apr 9, 2015 at 3:34 PM, stepharo <[hidden email]> wrote: Hi sean |
|
|
It will be a first "draft"
Stef Le 9/4/15 22:07, Tudor Girba a écrit :
|
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |