[Pharo-project] Beginner question :) search and replace in String
Method finder does not find a method for 'foobarqux' . 'bar' . 'XYZ' . 'fooXYZqux' and stupid me couldn't find a method on String either. How to get this done? +10 internets for solution with regex. --AA
On Thu, 31 Dec 2009, Adrian Kuhn wrote:
Method finder does not find a method for
'foobarqux' . 'bar' . 'XYZ' . 'fooXYZqux'
and stupid me couldn't find a method on String either.
'foobarqux' copyReplaceAll: 'bar' with: 'XYZ' Levente
How to get this done?
+10 internets for solution with regex.
--AA
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Levente Uzonyi <leves@...> writes:
Method finder does not find a method for
'foobarqux' . 'bar' . 'XYZ' . 'fooXYZqux'
and stupid me couldn't find a method on String either.
'foobarqux' copyReplaceAll: 'bar' with: 'XYZ'
Gosh, in SequencableCollection ... stoopid me :) Thank you Levente! --AA
BTW....shouldn't that be an issue that deserves opening a bug ticket ? On Thu, Dec 31, 2009 at 1:21 AM, Adrian Kuhn <akuhn@iam.unibe.ch> wrote:
Levente Uzonyi <leves@...> writes:
Method finder does not find a method for
'foobarqux' . 'bar' . 'XYZ' . 'fooXYZqux'
and stupid me couldn't find a method on String either.
'foobarqux' copyReplaceAll: 'bar' with: 'XYZ'
Gosh, in SequencableCollection ... stoopid me :)
Thank you Levente!
--AA
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Adrian this is fun because I was looking for the same recently and it worked like a charm with me. I retried and it worked on both 1.1 11128 and 1.0 rc On Dec 31, 2009, at 1:04 AM, Adrian Kuhn wrote:
Method finder does not find a method for
'foobarqux' . 'bar' . 'XYZ' . 'fooXYZqux'
and stupid me couldn't find a method on String either.
How to get this done?
+10 internets for solution with regex.
--AA
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse <stephane.ducasse@...> writes:
this is fun because I was looking for the same recently and it worked like a charm with me.
Mebbe my image is foobar. Anyway, the +10 bounty for a regex solution is still open! BTW, how do you search for operations involving none literal object with method finder? --AA
On Dec 31, 2009, at 4:02 PM, Adrian Kuhn wrote:
Stéphane Ducasse <stephane.ducasse@...> writes:
this is fun because I was looking for the same recently and it worked like a charm with me.
Mebbe my image is foobar.
Anyway, the +10 bounty for a regex solution is still open!
BTW, how do you search for operations involving none literal object with method finder?
You can I tried once with Date .... but you have to recreate the object via its representation (Date readFrom: '22 December 2009) kind of . Stef
--AA
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Anyway, the +10 bounty for a regex solution is still open!
'bar' asRegex copy: 'foobarqux' replacingMatchesWith: 'XYZ' Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Thu, 31 Dec 2009, Lukas Renggli wrote:
Anyway, the +10 bounty for a regex solution is still open!
'bar' asRegex copy: 'foobarqux' replacingMatchesWith: 'XYZ'
Or: 'foobarqux' copyWithRegex: 'bar' matchesReplacedWith: 'XYZ' Levente
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
This brings to the forum an interesting debate! Clearly Levente's solution is the String redirection for Lukas' solution. Do this method eases programming for newcomers? Or it creates burden as presented in Stan's posting? AK is IIUC very knowledgeable of tools used in Squeak/Pharo and even though, had difficulty to find this particular method!! my 0.019999... -- Cesar Rabak Em 31/12/2009 14:45, Levente Uzonyi <leves@elte.hu> escreveu: On Thu, 31 Dec 2009, Lukas Renggli wrote:
Anyway, the +10 bounty for a regex solution is still open!
'bar' asRegex copy: 'foobarqux' replacingMatchesWith: 'XYZ'
Or: 'foobarqux' copyWithRegex: 'bar' matchesReplacedWith: 'XYZ' Levente
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
<csrabak@...> writes:
This brings to the forum an interesting debate! Clearly Levente's solution is the String redirection for Lukas' solution.
Do this method eases programming for newcomers? Or it creates burden as presented in Stan's posting?
AK is IIUC very knowledgeable of tools used in Squeak/Pharo and even though, had difficulty to find this particular method!!
Good point! To replace parts of a string, I want to send a message to the string not to the regex. So without doubt, string should understand such a messages. (I dont know to which posting of Stan you're referring though). Also, I would expect short message names for common operations. Alas none of #copyWithRegex:matchesReplacedWith: #asRegex + #copy:replacingMatchesWith: #copyReplaceAll:with: is particular short. And to make things words, none of these shows up when auto completing #repl... because they all start with copy. Plus strings are nested in such a deep hierarchy that reading all understood messages won't scale. Personally, I would love to have a #gsub:with: on String. It is short and uses established vocabulary. --AA
On Thu, 31 Dec 2009, Adrian Kuhn wrote:
<csrabak@...> writes:
This brings to the forum an interesting debate! Clearly Levente's solution is the String redirection for Lukas' solution.
Do this method eases programming for newcomers? Or it creates burden as presented in Stan's posting?
AK is IIUC very knowledgeable of tools used in Squeak/Pharo and even though, had difficulty to find this particular method!!
Good point!
To replace parts of a string, I want to send a message to the string not to the regex. So without doubt, string should understand such a messages. (I dont know to which posting of Stan you're referring though).
Also, I would expect short message names for common operations. Alas none of
#copyWithRegex:matchesReplacedWith: #asRegex + #copy:replacingMatchesWith: #copyReplaceAll:with:
is particular short. And to make things words, none of these shows up when auto completing #repl... because they all start with copy. Plus strings are nested in such a deep hierarchy that reading all understood messages won't scale.
Personally, I would love to have a #gsub:with: on String. It is short and uses established vocabulary.
Please no, smalltalk is not awk or ruby and noone should expect that these cryptic function names are well known. Message names should be as descriptive as possible, this enables understanding the code without documentation. Short message names have no advantage, we are not in the 80's. Levente
--AA
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
+ 1 :)
Please no, smalltalk is not awk or ruby and noone should expect that these cryptic function names are well known. Message names should be as descriptive as possible, this enables understanding the code without documentation. Short message names have no advantage, we are not in the 80's.
Levente
--AA
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Levente Uzonyi <leves@...> writes:
Personally, I would love to have a #gsub:with: on String. It is short and uses established vocabulary.
Please no, smalltalk is not awk or ruby and noone should expect that these cryptic function names are well known. Message names should be as descriptive as possible, this enables understanding the code without documentation. Short message names have no advantage, we are not in the 80's.
I dare to disagree :) Growing a language *and* compressing it. There is two directions for natural growth of a language. Composing complex expressions from simple ones (see Guy Steele's classic OOPSLA keynote) *and* shortening the name of often the most common operations. The latter is clearly something that should happen overtime as an evolutionary process and not up front. Akira Tanaka refers to this as the "huffman coding" of API design. I have written about that on my blog [1]. So method names should initially be as descriptive as possible, but often used method names should get a short alias. In 80 when Smalltalk was fresh, #copyReplaceAll:with: was a revolutionary short "huffman encoding" for like 20 lines of C (or worse) code. Smalltalk was visionary in using long method names in the 80ies, but to each anti-thesis there is a synthesis. Today we are 30 years later, and "gsub" has established itself as a generally known name for replacing all occurrences of a pattern in a string. IMHO it has evolved from what once used to be a cryptic function name to a proper programming term of its own. We can think of other mebbe more Smalltalkesque huffman codings also, eg 'foobarqux' at: 'bar' put: 'XYZ'. with a double dispatch on the parameter of the #at: keyword, this would even open up the API of String for unlimited extensions by clients without cluttering it with dozens of new messages. So you could use integers, strings, regeces, et cetera... Well, just brainstorming :) --AA [1]: http://www.iam.unibe.ch/~akuhn/blog/2009/one-letter-method-names/
On Fri, 1 Jan 2010, Adrian Kuhn wrote:
Levente Uzonyi <leves@...> writes:
Personally, I would love to have a #gsub:with: on String. It is short and uses established vocabulary.
Please no, smalltalk is not awk or ruby and noone should expect that these cryptic function names are well known. Message names should be as descriptive as possible, this enables understanding the code without documentation. Short message names have no advantage, we are not in the 80's.
I dare to disagree :)
Growing a language *and* compressing it.
There is two directions for natural growth of a language. Composing complex expressions from simple ones (see Guy Steele's classic OOPSLA keynote) *and* shortening the name of often the most common operations. The latter is clearly something that should happen overtime as an evolutionary process and not up front. Akira Tanaka refers to this as the "huffman coding" of API design. I
Why didn't it happen to smalltalk? I guess because the language tries to mimic natural languages. Btw I can't come up with a language that changed it's core library function names to shorter ones.
have written about that on my blog [1].
I read your blog post and I think that your suggestions are not generally useful. In smalltalk where you can print, inspect and explore any object Object >> #p is not really useful. Logging to Transcript is a bad practice anyway. Object >> #h instead of #halt? You must be kidding. Saving 3 letters when you have code completion? List = OrderedCollection? List new ===> an OrderedCollection() ? Which is more readable? List new << 'Lorem' << 'ipsum' << 'dolor' vs { 'Lorem'. 'ipsum'. 'dolor' } 'Expected <1p> but got <2p> (using <3s>)' e: value e: expected e: symbol vs 'Expected <1p> but got <2p> (using <3s>)' expandMacrosWithArguments: { value. expected. symbol } 'Regex are aaaaaaaaaawesome!' =~ 'a*wesome'r vs 'Regex are aaaaaaaaaawesome!' matchesRegex: 'a*wesome' (Most of the time I use #format: instead of #expandMacros* and never seen any code using #expandMacros* that wasn't written by me, your code is the first. Possibly because it has no documentation/examples.)
So method names should initially be as descriptive as possible, but often used method names should get a short alias. In 80 when Smalltalk was fresh, #copyReplaceAll:with: was a revolutionary short "huffman encoding" for like 20 lines of C (or worse) code. Smalltalk was visionary in using long method names
#copyReplaceAll:with: is just a library method, a C library could have a similar function, but C libraries can't be explored like smalltalk libraries. In C you have to look up the docs or google a bit to find a function that fits your needs. In smalltalk you can browse the class hierarchy or in squeak/pharo you can use the MethodFinder besides the docs and the internet.
in the 80ies, but to each anti-thesis there is a synthesis. Today we are 30 years later, and "gsub" has established itself as a generally known name for replacing all occurrences of a pattern in a string. IMHO it has evolved from
People familiar with awk or ruby will know what gsub does but others won't. Levente
what once used to be a cryptic function name to a proper programming term of its own.
We can think of other mebbe more Smalltalkesque huffman codings also, eg
'foobarqux' at: 'bar' put: 'XYZ'.
with a double dispatch on the parameter of the #at: keyword, this would even open up the API of String for unlimited extensions by clients without cluttering it with dozens of new messages. So you could use integers, strings, regeces, et cetera...
Well, just brainstorming :)
--AA
[1]: http://www.iam.unibe.ch/~akuhn/blog/2009/one-letter-method-names/
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Levente Uzonyi <leves@...> writes:
Why didn't it happen to smalltalk? I guess because the language tries to mimic natural languages. Btw I can't come up with a language that changed it's core library function names to shorter ones.
The very same natural language argument can be used in favor of my point as well :) That is, if you *really* want to mimic the entire bandwidth of natural language, you should also mimic the tendency of natural languages to introduce abbreviations for common concepts. This is an *essential* part of any natural language. What should be said is that one should use whatever works best for himself. But a language that does not offer abbreviations to those that seek for them can IMHO not be called natural. The "huffman coding" presented in Akira's paper introduces shorter *aliases* for common methods. So you can pick and use what you want. So his paper is exactly about how they proceed when introducing short aliases in the evolution of the Ruby API. The full paper can be found here http://www.citeulike.org/article/6174874
Object >> #p is not really useful. Logging to Transcript is a bad practice anyway.
Print-outs are not *per se* bad practice. They have their justification and should be part of anyones debugging tool set. So even if you dont agree with abbreviating print-out to #p, you should not ban them from you tool set! For example, nothing beats print-outs when you need to trace a feed of events. You would not want to put an #inspect inside a loop that is taken 10'000 times :) Speaking of loops, I changed #h to abbreviate #haltOnce rather than #halt. At least for my style of debugging, that proofed to be more useful. I won't comment on the rest, some prefer concise language, some like to keep it verbose. My point is that a language should offer short aliases for common terms, and I guess all of my examples are common enough to qualify for a shorter aliases based on that criterion--if you want to mimic the evolution of abbreviations in natural language. --AA
On 05/01/2010 00:02, Adrian Kuhn wrote:
I won't comment on the rest, some prefer concise language, some like to keep it verbose. My point is that a language should offer short aliases for common terms, and I guess all of my examples are common enough to qualify for a shorter aliases based on that criterion--if you want to mimic the evolution of abbreviations in natural language.
Please bear in mind that natural languages have much more redundancy and less precision than programming languages. In addition, programming languages have handy tools like autocompletion that natural languages don't, making abbreviations less useful :)
Douglas Brebner <squeaklists@...> writes:
Please bear in mind that natural languages have much more redundancy and less precision than programming languages.
You are right! Personally I believe programming languages should strive to be as close to the the more stringent English of specification documents, and not to natural language with *all* its facets. The main line of argumentation in my previous mail was thus that the very argument of natural languages can be used in favor of my point as well :)
In addition, programming languages have handy tools like autocompletion that natural languages don't, making abbreviations less useful :)
That argument keeps popping up (eg from Ramon just in parallel to this answer, and also before) but I am not sure if auto completion is the whole story. For example in Object-C you have to write @"hello " stringByAppendingString: @"worlds!" to concatenate strings. Whereas in Smalltalk we just write 'hello ', 'worlds!' clearly both are as writable when you got auto completion, but isn't the second just more readable? In his "Elements of Style" William Strunk recommends to omit unnecessary word. With regard to source code, I'd say the lesson should be that more verbose is typically more readable but *not* always. So given this observation that sometimes operators (or single letters, which for that sake the same) are *sometimes* more readable than natural language, we can go an revisit the set of operators in Smalltalk and check if there might be more candidates. And I'd be more than surprised if are were not some more candidates for abbreviation. For example Pharo already got #<< for appending to a stream, so the same would make sense to append elements to a collecton, such that we can write list := List new << 'lorem' << 'ipsum' << 'dolor'. et cetera. --AA
Em 06/01/2010 11:18, Adrian Kuhn < akuhn@iam.unibe.ch > escreveu:
Douglas Brebner writes:
Please bear in mind that natural languages have much more redundancy and less precision than programming languages. You are right! Personally I believe programming languages should strive to be as close to the the more stringent English of specification documents, and not to natural language with *all* its facets. The main line of argumentation in my previous mail was thus that the very argument of natural languages can be used in favor of my point as well :)
In addition, programming languages have handy tools like autocompletion that natural languages don't, making abbreviations less useful :) That argument keeps popping up (eg from Ramon just in parallel to this answer, and also before) but I am not sure if auto completion is the whole story. For example in Object-C you have to write
@"hello " stringByAppendingString: @"worlds!"
to concatenate strings. Whereas in Smalltalk we just write
'hello ', 'worlds!'
clearly both are as writable when you got auto completion, but isn't the second just more readable?
Two points on "more readable". _Right now_ to Smalltalkers that know by heart that #, is a concatenation operator, it seems *less cluttered* and thus it appears more readable. Put forward some twenty to fifty years (or to do it right now ask a girlfriend that doesn't know nor Objective C nor Smalltalk) to see what of two expressions convene more meaning. As everybody else knows :-P the string concatenation operator is '+', right!? So #, needs to be explained anyway. . .
In his "Elements of Style" William Strunk recommends to omit unnecessary word. With regard to source code, I'd say the lesson should be that more verbose is typically more readable but *not* always. So given this observation that sometimes operators (or single letters, which for that sake the same) are *sometimes* more readable than natural language, we can go an revisit the set of operators in Smalltalk and check if there might be more candidates. And I'd be more than surprised if are were not some more candidates for abbreviation. For example Pharo already got #<< for appending to a stream, so the same would make sense to append elements to a collecton, such that we can write
list := List new << 'lorem' << 'ipsum' << 'dolor'. et cetera.
This may lead to the same problem we already have with #, namely it is slow and not recommended for repeated operations. We have to strike a balance between the easiness for writing the code with the implementation that will run it. my 0.019999.... -- Cesar Rabak
On Wed, 6 Jan 2010, csrabak@bol.com.br wrote:
Em 06/01/2010 11:18, Adrian Kuhn < akuhn@iam.unibe.ch > escreveu:
Douglas Brebner writes:
Please bear in mind that natural languages have much more redundancy and less precision than programming languages. You are right! Personally I believe programming languages should strive to be as close to the the more stringent English of specification documents, and not to natural language with *all* its facets. The main line of argumentation in my previous mail was thus that the very argument of natural languages can be used in favor of my point as well :)
In addition, programming languages have handy tools like autocompletion that natural languages don't, making abbreviations less useful :) That argument keeps popping up (eg from Ramon just in parallel to this answer, and also before) but I am not sure if auto completion is the whole story. For example in Object-C you have to write
@"hello " stringByAppendingString: @"worlds!"
to concatenate strings. Whereas in Smalltalk we just write
'hello ', 'worlds!'
clearly both are as writable when you got auto completion, but isn't the second just more readable?
Two points on "more readable". _Right now_ to Smalltalkers that know by heart that #, is a concatenation operator, it seems *less cluttered* and thus it appears more readable.
Put forward some twenty to fifty years (or to do it right now ask a girlfriend that doesn't know nor Objective C nor Smalltalk) to see what of two expressions convene more meaning.
As everybody else knows :-P the string concatenation operator is '+', right!? So #, needs to be explained anyway. . .
You're wrong, it's '.'. :)
In his "Elements of Style" William Strunk recommends to omit unnecessary word. With regard to source code, I'd say the lesson should be that more verbose is typically more readable but *not* always. So given this observation that sometimes operators (or single letters, which for that sake the same) are *sometimes* more readable than natural language, we can go an revisit the set of operators in Smalltalk and check if there might be more candidates. And I'd be more than surprised if are were not some more candidates for abbreviation. For example Pharo already got #<< for appending to a stream, so the same would make sense to append elements to a collecton, such that we can write
list := List new << 'lorem' << 'ipsum' << 'dolor'. et cetera.
This may lead to the same problem we already have with #, namely it is slow and not recommended for repeated operations.
No, it's fast, because it doesn't create copies. Of course to know that you also have to know that List is an alias for OrderedCollection... It's just a C++ism that makes your code slower. :) Levente
We have to strike a balance between the easiness for writing the code with the implementation that will run it.
my 0.019999....
-- Cesar Rabak
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Em 06/01/2010 17:30, Levente Uzonyi < leves@elte.hu > escreveu:
On Wed, 6 Jan 2010, csrabak@bol.com.br wrote: [snipped]
As everybody else knows :-P the string concatenation operator is '+', right!? So #, needs to be explained anyway. . . You're wrong, it's '.'. :)
You know this polyglot approach to programming ends up with some confusion :-) [snipped]
This may lead to the same problem we already have with #, namely it is slow and not recommended for repeated operations.
No, it's fast, because it doesn't create copies. Of course to know that you also have to know that List is an alias for OrderedCollection... It's just a C++ism that makes your code slower. :)
Levente, In a ordinary (sort of, it's a dev image, Pharo 1.0 #10503, there is no List class, and: Collection>>, aCollection ^self copy addAll: aCollection; yourself Which creates copies for each #, method send, right? Or do I miss something here? -- Cesar Rabak
On Wed, 6 Jan 2010, csrabak@bol.com.br wrote:
Em 06/01/2010 17:30, Levente Uzonyi < leves@elte.hu > escreveu:
On Wed, 6 Jan 2010, csrabak@bol.com.br wrote: [snipped]
As everybody else knows :-P the string concatenation operator is '+', right!? So #, needs to be explained anyway. . . You're wrong, it's '.'. :)
You know this polyglot approach to programming ends up with some confusion :-)
[snipped]
This may lead to the same problem we already have with #, namely it is slow and not recommended for repeated operations.
No, it's fast, because it doesn't create copies. Of course to know that you also have to know that List is an alias for OrderedCollection... It's just a C++ism that makes your code slower. :)
Levente,
In a ordinary (sort of, it's a dev image, Pharo 1.0 #10503, there is no List class, and:
Collection>>, aCollection ^self copy addAll: aCollection; yourself
Which creates copies for each #, method send, right? Or do I miss something here?
Yes you do, List is one of Adrian's ideas to Huffman code smalltalk. Details here http://www.iam.unibe.ch/~akuhn/blog/2009/one-letter-method-names/ Levente
-- Cesar Rabak
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Em 06/01/2010 22:06, Levente Uzonyi < leves@elte.hu > escreveu:
On Wed, 6 Jan 2010, csrabak@bol.com.br wrote:
Em 06/01/2010 17:30, Levente Uzonyi < leves@elte.hu > escreveu:
On Wed, 6 Jan 2010, csrabak@bol.com.br wrote: [snipped]
As everybody else knows :-P the string concatenation operator is '+', right!? So #, needs to be explained anyway. . . You're wrong, it's '.'. :) You know this polyglot approach to programming ends up with some confusion :-) [snipped]
This may lead to the same problem we already have with #, namely it is slow and not recommended for repeated operations. No, it's fast, because it doesn't create copies. Of course to know that you also have to know that List is an alias for OrderedCollection... It's just a C++ism that makes your code slower. :) Levente, In a ordinary (sort of, it's a dev image, Pharo 1.0 #10503, there is no List class, and:
Collection>>, aCollection ^self copy addAll: aCollection; yourself Which creates copies for each #, method send, right? Or do I miss something here? Yes you do, List is one of Adrian's ideas to Huffman code smalltalk. Details here http://www.iam.unibe.ch/~akuhn/blog/2009/one-letter-method-names/
Ok Levente! In this case after reading Adrian's blog post, I would say "List" is not a good choice: VW uses List for a different kind of object (a descendant from OrderedCollection, in fact). As a side note, IMNHO Object>>out (as Travis' idea) seems to me better than Object>>p for the same purpose. Regards, -- Cesar Rabak
On 1/4/2010 5:02 PM, Adrian Kuhn wrote:
Levente Uzonyi<leves@...> writes: That is, if you *really* want to mimic the entire bandwidth of natural language, you should also mimic the tendency of natural languages to introduce abbreviations for common concepts. This is an *essential* part of any natural language.
IMHO, abbreviations are evil and have no place in Smalltalk and is not an essential part of natural *spoken* language. If one can't read one's code out loud in plain words, then something is wrong with the code. Abbreviations make no sense at all in the era of code completion and intellisense. -- Ramon Leon http://onsmalltalk.com
Em 31/12/2009 15:52, Adrian Kuhn <akuhn@iam.unibe.ch> escreveu:
This brings to the forum an interesting debate! Clearly Levente's solution is the String redirection for Lukas' solution. Do this method eases programming for newcomers? Or it creates burden as presented in Stan's posting? AK is IIUC very knowledgeable of tools used in Squeak/Pharo and even though, had difficulty to find this particular method!! Good point! To replace parts of a string, I want to send a message to the string not to the regex. So without doubt, string should understand such a messages. (I dont know to which posting of Stan you're referring though).
OK, so the redirection of the messages to String makes sense. I would only gripe about the protocol it appears right now: *vb-regex is the _implementation_ of the method's functionality, but from a [programer] user POV it would be more likely to another one (perhaps "searching and replace").
Also, I would expect short message names for common operations. Alas none of
#copyWithRegex:matchesReplacedWith: asRegex + ##copy:replacingMatchesWith: copyReplaceAll:with: is particular short. And to make things words, none of these shows up when auto completing #repl... because they all start with copy. Plus strings are nested in such a deep hierarchy that reading all understood messages won't scale.
Alas, I normally stay away of these discussions because I'm intoxicated by other programming idioms (like sed/AWK/Perl/Python/Ruby) which uses a very compact syntax for these operations and are now a lingua franca.
Personally, I would love to have a #gsub:with: on String. It is short and uses established vocabulary.
Yes it would be an adaptation of the above idioms to Smalltalk.
On Thu, 31 Dec 2009, csrabak@bol.com.br wrote:
This brings to the forum an interesting debate! Clearly Levente's solution is the String redirection for Lukas' solution.
Do this method eases programming for newcomers? Or it creates burden as presented in Stan's posting?
Definitely, if you know how to search for methods. I was looking for a regex solution and found it in the *VB-regex category.
AK is IIUC very knowledgeable of tools used in Squeak/Pharo and even though, had difficulty to find this particular method!!
MethodFinder is not up-to-date. Levente
my 0.019999...
-- Cesar Rabak
Em 31/12/2009 14:45, Levente Uzonyi <leves@elte.hu> escreveu:
On Thu, 31 Dec 2009, Lukas Renggli wrote:
Anyway, the +10 bounty for a regex solution is still open!
'bar' asRegex copy: 'foobarqux' replacingMatchesWith: 'XYZ'
Or: 'foobarqux' copyWithRegex: 'bar' matchesReplacedWith: 'XYZ'
Levente
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (8)
-
Adrian Kuhn -
csrabak＠bol.com.br -
Douglas Brebner -
Levente Uzonyi -
Lukas Renggli -
Mariano Martinez Peck -
Ramon Leon -
Stéphane Ducasse