Want: #slice: (Re: [squeak-dev] Noob question: array slice?)

> On Fri, Aug 6, 2010 at 5:06 AM, Casey Ransberger
> <[hidden email]> wrote:
>> I get that, now, but thanks. What I really want, though, is to have a method in the system named something starting with 'slice,' because that's what I (and most of my friends, really,) would look for when trying to do the thing I was trying to do when I couldn't find a method that did what I wanted to do. When I think about grabbing a subset of a SequenceableCollection, I don't think to use the word 'copy' to find what I'm looking for.
>
> There are lots of things in Smalltalk with odd names.  My favorite
> example is inject:into: with ought to have "reduce" in its name.  Some
> are new or little used and so not hard to change.   Some are well
> established and so have become part of the language and so are hard to
> change.  Of course, "hard" doesn't mean "impossible".  But it would
> probably take a long and concerted effort to get people to change this
> name, and the chance of failure is high.
>
> It is easy to change Smalltalk for yourself.   It is hard to get other
> people to change theirs.  Even if you got your methods into Squeak, a
> lot of people would avoid using them because they would want their
> code to be compatible with other Smalltalks.
>
> -Ralph
>

> 2010/8/6 Bert Freudenberg <[hidden email]>
>> To find the sine function you could give
>>
>>        60. 0.5
>>
> Not to confuse people that this will correctly list degreeCos. Since this is an artificial example
>
> Float pi. 0.
>
> used in the method finder will give you a hint for the sine function
>
> Alex

> After I looked up the name for copyFrom:to:, I decided to find it with
> method finder.  I don't use method finder much, which is my own
> failing.  I had to play around with it a bit because Bert's original
> input didn't work for me.   What worked was
>  'Hello'. 2 . 4 . 'ell'
> which gave me copyFrom:to: as the only answer
>
> Every time I use method finder I ask myself why I don't use it more!
> "Intro to Squeak" documentation, including my own, should emphasize it
> more.
>
> But method finder has its limits.  'Hello'. (2 to: 4). 'ell' doesn't
> show anything, because there is no method with that exact combination
> of arguments.
>
> -Ralph

>>>>>> "Casey" == Casey Ransberger <[hidden email]> 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.'
>
> It takes only a few hours with Smalltalk to learn that Smalltalk uses
> its own terminology for a lot of things, and then how to search for such
> things, regardless of their name.
>
> 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".
>

> On 6 August 2010 17:45, Randal L. Schwartz<[hidden email]>  wrote:
>>>>>>> "Casey" == Casey Ransberger<[hidden email]>  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.

> On 8/6/2010 6:20 PM, Igor Stasenko wrote:
>>
>> On 6 August 2010 17:45, Randal L. Schwartz<[hidden email]>  wrote:
>>>>>>>>
>>>>>>>> "Casey" == Casey Ransberger<[hidden email]>  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).
>

> On 7 August 2010 06:56, Andreas Raab <[hidden email]> wrote:
>> On 8/6/2010 6:20 PM, Igor Stasenko wrote:
>>>
>>> On 6 August 2010 17:45, Randal L. Schwartz<[hidden email]>  wrote:
>>>>>>>>>
>>>>>>>>> "Casey" == Casey Ransberger<[hidden email]>  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 looks like form of #select: , where you selecting based on
> collection's keys, not values.
> (for arrayed collections a key is an element's index).
>
> So, it could be named #selectKeys:
>
> collection selectKeys: (1 to:10)
>
> or
>
> dictionary selectKeys: #(firstName lastName)
>

> The problem is, that not all collections having a notion of keys. Sets
> don't have a keys. Bags too.
> Any meaningful example, what #slice would mean for Set or Bag?
>
> So, in this form its not generic enough for introducing in the root
> class. Only for classes, which having notion of keys.
>
>> 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).
>>
> err... did you meant following:
>
> aCollection select: [:each | each odd ]
>
> ?
>
>> 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:.
>>
>
> copying is slow and always will be. That's why i told that i trying to
> avoid it, if its possible.
>
>> Cheers,
>>  - Andreas
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

> On 8/6/2010 6:20 PM, Igor Stasenko wrote:
>> On 6 August 2010 17:45, Randal L. Schwartz<[hidden email]>  wrote:
>>>>>>>> "Casey" == Casey Ransberger<[hidden email]>  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:.

>
> 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<[hidden email]>  wrote:
>>>>>>>>> "Casey" == Casey Ransberger<[hidden email]>  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 -

>
> 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<[hidden email]>  wrote:
>>>>>>>>>> "Casey" == Casey Ransberger<[hidden email]>  
>>>>>>>>>> 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?)