String operations
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
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 <i.uhnak@gmail.com>:
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 <norbert@hartl.name> wrote:
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 <i.uhnak@gmail.com>:
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
-- www.tudorgirba.com "Every thing has its own flow"
Am 06.04.2015 um 21:28 schrieb Tudor Girba <tudor@tudorgirba.com>:
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.
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
Cheers, Doru
On Mon, Apr 6, 2015 at 12:51 PM, Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>> wrote: 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 <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>>:
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
-- www.tudorgirba.com <http://www.tudorgirba.com/>
"Every thing has its own flow"
'BormParticipant' allButFirst: 4
('BormParticipant' splitOn: 'Borm') last Thank you both, this will work. :) 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.
Isn't it the case that a remove* methods mostly return what has been removed? Wouldn't be
withoutPrefix: withoutSuffix:
I guess withoutPrefix: would probably makes more sense. Thanks, Peter
Am 07.04.2015 um 21:31 schrieb Peter Uhnák <i.uhnak@gmail.com>:
'BormParticipant' allButFirst: 4 ('BormParticipant' splitOn: 'Borm') last Thank you both, this will work. :)
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.
Isn't it the case that a remove* methods mostly return what has been removed? Wouldn't be
withoutPrefix: withoutSuffix: I guess withoutPrefix: would probably makes more sense.
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 <norbert@hartl.name> wrote:
Am 07.04.2015 um 21:31 schrieb Peter Uhnák <i.uhnak@gmail.com>:
'BormParticipant' allButFirst: 4
('BormParticipant' splitOn: 'Borm') last
Thank you both, this will work. :)
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.
Isn't it the case that a remove* methods mostly return what has been removed? Wouldn't be
withoutPrefix: withoutSuffix:
I guess withoutPrefix: would probably makes more sense.
As well as
allButPrefix: allButSuffix:
but to me the sound of them is weird.
Norbert
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.
Perfectly stated..! btw, I really liked the python string API's when I worked with them. simple, intuitive but effective in nearly all that I needed in it. On Thu, Apr 9, 2015 at 12:59 PM, Sean P. DeNigris <sean@clipperadams.com> 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.
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.
Great. I am interested in providing feedback. Doru On Thu, Apr 9, 2015 at 3:34 PM, stepharo <stepharo@free.fr> wrote:
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.
-- www.tudorgirba.com "Every thing has its own flow"
It will be a first "draft" Stef Le 9/4/15 22:07, Tudor Girba a écrit :
Great. I am interested in providing feedback.
Doru
On Thu, Apr 9, 2015 at 3:34 PM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
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.
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
+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 <sean@clipperadams.com> 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.
+ 1 :) can you open a bug entry and I prefer withoutPrefix:, withoutSuffix: Stef Le 6/4/15 21:28, Tudor Girba a écrit :
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 <norbert@hartl.name <mailto:norbert@hartl.name>> wrote:
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 <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>>: > > 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
-- www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
participants (9)
-
Damien Pollet -
Henrik Johansen -
Hilaire -
Norbert Hartl -
Peter Uhnák -
S Krish -
Sean P. DeNigris -
stepharo -
Tudor Girba