On 8/6/2010 6:20 PM, Igor Stasenko wrote:
> On 6 August 2010 17:45, Randal L. Schwartz<merlyn at stonehenge.com>  wrote:
>>>>>>> "Casey" == Casey Ransberger<casey.obrien.r at gmail.com>  writes:
>>
>> Casey>  It's literally adding a method to make the cuneiform smalltalk
>> Casey>  crap accessible to new people, who are liable to search on terms
>> Casey>  like 'slice.'
>>
>> What you are asking for is something that would be useful for only
>> those first few hours, and then be a maintenance clutter for the
>> remaining years of programming.
>>
>> I vote "-1".
>>
> +1 to your -1.

I vote -2 on your -1 which should leave us at +0 I think :-)=)

No, seriously. I think there's actually a pretty good and generic 
interpretation of slice if you consider it to be an operation that can 
collect arbitrary sequences. For example:

Collection>>slice: aCollection
	"Slice the receiver by aCollection, collecting all elements
	in the receiver that are keyed by aCollection."

	^aCollection collect:[:each| self at: each] as: self species.

With a polymorphic implementation this would allow some interesting uses 
that are quite difficult to implement otherwise, for example:

	dd := Dictionary newFromPairs: {
		'firstName'. 'Joe'.
		'lastName'. 'Sixpack'
		'dob'. '01-01-2001'.
		'zip'. '12345'
	}.
	dd slice: #(firstName lastName).

This would return a dictionary with only firstName and lastName. And of 
course, when used with intervals it would behave identical to 
#copyFrom:to: just somewhat less efficient, but that's offset by, say, 
uses such as:

	"Slice out all the odd elements"
	aCollection slice: (1 to: aCollection size by: 2).

Etc. So I think the argument for #slice: can be made and we should 
consider it as a more generic operation instead of just a slower version 
of #copyFrom:to:.

Cheers,
   - Andreas