Quantcast

Smalltalk string API

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Smalltalk string API

Nicolas Cellier
I started referencing Smalltalk idioms at
http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(string_functions)
I could have focused on ANSI but have chosen Squeak/Pharo. Feel free
to correct me and to complete me.

This is a very enlighting exercize, especially for pointing when API
turns to be not that bright.
During my perigrination, I notably noticed this:

#compare: returns 1, 2, or 3 : this is both very object oriented, very
intuitive and very standard and the rest of the world is stupid,
unless...

#findLastOccurrenceOfString:startingAt: in its current form is stupid
to my taste, because
1) implementation is inefficient
2) the startingAt: only skip the beginning of the string which seems
odd for a rfind operation
I would rather expect this kind of usage:
last := aString findLastOccurrenceOfString: 'to' startingAt: aString size.
lastButOne := aString findLastOccurrenceOfString: 'to' startingAt: last - 1.

The CamelCase is sometimes abusive like #includesSubString:

There is no format. I know, purists will tell me that encoding a
format in a cryptic string is not in the Smalltalk spirit, but please
then tell me how to specify a formatting efficiently and also remove
cryptic regex encoding (a pity, it's not in trunk).

I let a few holes (split/join etc...)

Cheers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Smalltalk string API

SergeStinckwich
On Wed, Feb 16, 2011 at 4:24 PM, Nicolas Cellier
<[hidden email]> wrote:

> I started referencing Smalltalk idioms at
> http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(string_functions)
> I could have focused on ANSI but have chosen Squeak/Pharo. Feel free
> to correct me and to complete me.
>
> This is a very enlighting exercize, especially for pointing when API
> turns to be not that bright.
> During my perigrination, I notably noticed this:
>
> #compare: returns 1, 2, or 3 : this is both very object oriented, very
> intuitive and very standard and the rest of the world is stupid,
> unless...

Yes, really stupid, but maybe Squeak/Pharo should align here to the
rest of the world or
better, remove this method. We could use comparaison methods instead: <, >, ...

--
Serge Stinckwich
UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
Every DSL ends up being Smalltalk
http://doesnotunderstand.org/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Smalltalk string API

Stéphane Ducasse
In reply to this post by Nicolas Cellier
Hi nicolas

propose something and we can react :)
I'm busy with project proposal, teaching and 1.2 right now.

Stef


On Feb 16, 2011, at 10:24 AM, Nicolas Cellier wrote:

> I started referencing Smalltalk idioms at
> http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(string_functions)
> I could have focused on ANSI but have chosen Squeak/Pharo. Feel free
> to correct me and to complete me.
>
> This is a very enlighting exercize, especially for pointing when API
> turns to be not that bright.
> During my perigrination, I notably noticed this:
>
> #compare: returns 1, 2, or 3 : this is both very object oriented, very
> intuitive and very standard and the rest of the world is stupid,
> unless...
>
> #findLastOccurrenceOfString:startingAt: in its current form is stupid
> to my taste, because
> 1) implementation is inefficient
> 2) the startingAt: only skip the beginning of the string which seems
> odd for a rfind operation
> I would rather expect this kind of usage:
> last := aString findLastOccurrenceOfString: 'to' startingAt: aString size.
> lastButOne := aString findLastOccurrenceOfString: 'to' startingAt: last - 1.
>
> The CamelCase is sometimes abusive like #includesSubString:
>
> There is no format. I know, purists will tell me that encoding a
> format in a cryptic string is not in the Smalltalk spirit, but please
> then tell me how to specify a formatting efficiently and also remove
> cryptic regex encoding (a pity, it's not in trunk).
>
> I let a few holes (split/join etc...)
>
> Cheers
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [squeak-dev] Re: Smalltalk string API

Bert Freudenberg
In reply to this post by SergeStinckwich

On 16.02.2011, at 10:39, Serge Stinckwich wrote:

> On Wed, Feb 16, 2011 at 4:24 PM, Nicolas Cellier
> <[hidden email]> wrote:
>> I started referencing Smalltalk idioms at
>> http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(string_functions)
>> I could have focused on ANSI but have chosen Squeak/Pharo. Feel free
>> to correct me and to complete me.
>>
>> This is a very enlighting exercize, especially for pointing when API
>> turns to be not that bright.
>> During my perigrination, I notably noticed this:
>>
>> #compare: returns 1, 2, or 3 : this is both very object oriented, very
>> intuitive and very standard and the rest of the world is stupid,
>> unless...
>
> Yes, really stupid, but maybe Squeak/Pharo should align here to the
> rest of the world or
> better, remove this method. We could use comparaison methods instead: <, >, ...

It is a low-level primitive, better indeed to use those operators instead, not call the compare* methods directly. For case-insensitive comparisons you should use e.g. caseInsensitiveLessOrEqual:.

If we want to provide a method that answers -1, 0, and 1 I'd leave the #compare: family alone, and instead add the operator <=> as in Ruby (which would be case-sensitive).

My 0.02€

- Bert -



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [squeak-dev] Smalltalk string API

Tobias Pape
In reply to this post by Nicolas Cellier
Hi,

Am 2011-02-16 um 10:24 schrieb Nicolas Cellier:

> I started referencing Smalltalk idioms at
> http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(string_functions)
> I could have focused on ANSI but have chosen Squeak/Pharo. Feel free
> to correct me and to complete me.
>
> This is a very enlighting exercize, especially for pointing when API
> turns to be not that bright.
> During my perigrination, I notably noticed this:
>
> #compare: returns 1, 2, or 3 : this is both very object oriented, very
> intuitive and very standard and the rest of the world is stupid,
> unless...
>
> #findLastOccurrenceOfString:startingAt: in its current form is stupid
> to my taste, because
> 1) implementation is inefficient
> 2) the startingAt: only skip the beginning of the string which seems
> odd for a rfind operation
> I would rather expect this kind of usage:
> last := aString findLastOccurrenceOfString: 'to' startingAt: aString size.
> lastButOne := aString findLastOccurrenceOfString: 'to' startingAt: last - 1.
>
> The CamelCase is sometimes abusive like #includesSubString:

While I’m with you in the preceding part,
the following is incorrect:
>
> There is no format. I know, purists will tell me that encoding a
> format in a cryptic string is not in the Smalltalk spirit, but please
> then tell me how to specify a formatting efficiently and also remove
> cryptic regex encoding (a pity, it's not in trunk).

see String>>format:
        "format the receiver with aCollection  
         
        simplest example:  
        'foo {1} bar' format: {Date today}.
         
        complete example:  
        '\{ \} \\ foo {1} bar {2}' format: {12. 'string'}.
        "

as well as the String>>expandMacros* methods. The latter
seem more elaborate but unused, however.


So Long,
        -Tobias




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Smalltalk string API

csrabak
In reply to this post by Stéphane Ducasse
Incurring on the risk of appearing obvious:

for the rant on the "very object oriented, very intuitive and very standard", I think we could create three symbols: #lesser, #equal, #greater, and return then instead of 1,2 and 3.

my 0.0199...

--
Cesar Rabak


Em 16/02/2011 07:56, Stéphane Ducasse < [hidden email] > escreveu:
Hi nicolas

propose something and we can react :)
I'm busy with project proposal, teaching and 1.2 right now.

Stef


On Feb 16, 2011, at 10:24 AM, Nicolas Cellier wrote:

> I started referencing Smalltalk idioms at
> http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(string_functions)
> I could have focused on ANSI but have chosen Squeak/Pharo. Feel free
> to correct me and to complete me.
>
> This is a very enlighting exercize, especially for pointing when API
> turns to be not that bright.
> During my perigrination, I notably noticed this:
>
> #compare: returns 1, 2, or 3 : this is both very object oriented, very
> intuitive and very standard and the rest of the world is stupid,
> unless...
>
> #findLastOccurrenceOfString:startingAt: in its current form is stupid
> to my taste, because
> 1) implementation is inefficient
> 2) the startingAt: only skip the beginning of the string which seems
> odd for a rfind operation
> I would rather expect this kind of usage:
> last := aString findLastOccurrenceOfString: 'to' startingAt: aString size.
> lastButOne := aString findLastOccurrenceOfString: 'to' startingAt: last - 1.
>
> The CamelCase is sometimes abusive like #includesSubString:
>
> There is no format. I know, purists will tell me that encoding a
> format in a cryptic string is not in the Smalltalk spirit, but please
> then tell me how to specify a formatting efficiently and also remove
> cryptic regex encoding (a pity, it's not in trunk).
>
> I let a few holes (split/join etc...)
>
> Cheers
>




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Smalltalk string API

Nicolas Cellier
In which namespace would these symbols be defined ? TextConstants ?
I don't think it is at all necessary to consume 3 symbols for a low
level mostly unused method.
If method is candidate for wikipedia pages, then we should use the
well known least surprising standard.
If method is private, then I should remove it from wikipedia.
Bert is right, we can use anything then, but still I would have
prefered least surprising standards.

Anyway, putting dialect specific messages in wikipedia rather than
ANSI is questionnable.

Nicolas


2011/2/16  <[hidden email]>:

> Incurring on the risk of appearing obvious:
>
> for the rant on the "very object oriented, very intuitive and very standard", I think we could create three symbols: #lesser, #equal, #greater, and return then instead of 1,2 and 3.
>
> my 0.0199...
>
> --
> Cesar Rabak
>
>
> Em 16/02/2011 07:56, Stéphane Ducasse < [hidden email] > escreveu:
> Hi nicolas
>
> propose something and we can react :)
> I'm busy with project proposal, teaching and 1.2 right now.
>
> Stef
>
>
> On Feb 16, 2011, at 10:24 AM, Nicolas Cellier wrote:
>
>> I started referencing Smalltalk idioms at
>> http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(string_functions)
>> I could have focused on ANSI but have chosen Squeak/Pharo. Feel free
>> to correct me and to complete me.
>>
>> This is a very enlighting exercize, especially for pointing when API
>> turns to be not that bright.
>> During my perigrination, I notably noticed this:
>>
>> #compare: returns 1, 2, or 3 : this is both very object oriented, very
>> intuitive and very standard and the rest of the world is stupid,
>> unless...
>>
>> #findLastOccurrenceOfString:startingAt: in its current form is stupid
>> to my taste, because
>> 1) implementation is inefficient
>> 2) the startingAt: only skip the beginning of the string which seems
>> odd for a rfind operation
>> I would rather expect this kind of usage:
>> last := aString findLastOccurrenceOfString: 'to' startingAt: aString size.
>> lastButOne := aString findLastOccurrenceOfString: 'to' startingAt: last - 1.
>>
>> The CamelCase is sometimes abusive like #includesSubString:
>>
>> There is no format. I know, purists will tell me that encoding a
>> format in a cryptic string is not in the Smalltalk spirit, but please
>> then tell me how to specify a formatting efficiently and also remove
>> cryptic regex encoding (a pity, it's not in trunk).
>>
>> I let a few holes (split/join etc...)
>>
>> Cheers
>>
>
>
>
>
>

Loading...