On Aug 7, 2010, at 3:34 AM, Bert Freudenberg wrote:

>
> On 07.08.2010, at 12:29, Bert Freudenberg wrote:
>
>>
>> On 07.08.2010, at 05:56, Andreas Raab wrote:
>>
>>> 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:.
>>
>> But we have that already. It's called #atAll: which is nicely  
>> consistent with the rest of the collection protocols. We just need  
>> to add a more generic version in Collection.
>>
>> - Bert -
>
> That said, having a Subsequence object like Travis mentioned would  
> warrant adding a new protocol. I seem to remember seeing something  
> like this in Squeak before (MappedCollection maybe?)

I didn't actually add a new protocol. Per se. I admit to adding some  
particular "helpers." Instead, I placed the burden on the Subsequence  
class. The reason I did this, was that we actually use a couple  
different kinds of Subsequences in the differencing engine. You can  
have a general purpose Subsequence class that does the general things  
that SequenceableCollection (SC) can do, but then what happens when  
you want refined behavior on a subsequence?  Or you want to  
differentiate thru polymorphic types how you interact with different  
"slices." So in VW for example, there is a TextFragment subclass of  
Subsequence. It's really meant to work with CharacterArrays. And then  
there's 3 different subclasses for difference differentiation:  
InsertSequence, DeleteSequence, MatchSequence. If I had tried to put  
the burden of creating these different kinds of subsequences on SC, it  
would be a potential method explosion. It was simpler easier, and even  
more clear (to me) to make it clear what kind of slice I was creating.

At Key Tech, we had something similar to the Subsequence class, called  
a ReindexedCollection. It used an Interval object for the mapping.  
Which was actually *very* useful for image processing standard argb32  
images. You could write code like:

Bag withAll: (image bitsInstVar from: 2 by: 4)

And that would give you a histogram of the red channel of an image,  
or...

(image bitsInstVar from: 3 by: 4) median

to get the median green value in an image.

--
Travis Griggs
Objologist
"I did not have time to write you a short program, so I wrote you a  
long one instead."