- Pharo-users - lists.pharo.org

Re: [Pharo-users] String operations

by stepharo

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. > >

April 9, 2015

Re: [Pharo-users] String operations

by stepharo

+ 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(a)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(a)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"

April 9, 2015

Re: [Pharo-users] STON can't handle classes?

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > Yes, that is a know limitation... I usually store just the symbol name. Thanks :) That's what I ended up doing as well. ----- Cheers, Sean -- View this message in context: http://forum.world.st/STON-can-t-handle-classes-tp4818547p4818572.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 9, 2015

Re: [Pharo-users] STON can't handle classes?

by Sven Van Caekenberghe

Yes, that is a know limitation, classes can't be serialised. The same is true for many system like objects. I usually store just the symbol name. > On 09 Apr 2015, at 13:24, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > "STON toStringPretty: Class" -> MessageNotUnderstood: > Metaclass>>stonAllInstVarNames > > Is that a known limitation? Is there a workaround? Thanks. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/STON-can-t-handle-classes-tp4818547.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

April 9, 2015

Re: [Pharo-users] String operations

by S Krish

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(a)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. > >

April 9, 2015

STON can't handle classes?

by Sean P. DeNigris

"STON toStringPretty: Class" -> MessageNotUnderstood: Metaclass>>stonAllInstVarNames Is that a known limitation? Is there a workaround? Thanks. ----- Cheers, Sean -- View this message in context: http://forum.world.st/STON-can-t-handle-classes-tp4818547.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 9, 2015

Re: [Pharo-users] GT: Pasting a PrintIt

by Tudor Girba

Yeah, we had quite some debates about this one :). You meant GT team, but you should thank Esteban more this time :) Doru On Thu, Apr 9, 2015 at 12:49 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > "cmd-p then [Enter]" copy/pastes the PrintIt into the underlying editor... > Cool! I don't need it often, but that's very convenient. Thanks, Moose team > :) > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/GT-Pasting-a-PrintIt-tp4818537.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > -- www.tudorgirba.com "Every thing has its own flow"

April 9, 2015

Re: [Pharo-users] String operations

by Sean P. DeNigris

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.

April 9, 2015

GT: Pasting a PrintIt

by Sean P. DeNigris

"cmd-p then [Enter]" copy/pastes the PrintIt into the underlying editor... Cool! I don't need it often, but that's very convenient. Thanks, Moose team :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/GT-Pasting-a-PrintIt-tp4818537.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 9, 2015

Re: [Pharo-users] String operations

by Damien Pollet

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(a)hartl.name> wrote: > > Am 07.04.2015 um 21:31 schrieb Peter UhnÃ¡k <i.uhnak(a)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 > >

April 9, 2015