Re: #sortBlock:

>> #sortBlock: is defined by ANSI on SortedCollection as an accessor and
>>>> an instance creation method. That's what it sounds like and shouldn't
>>>> be implemented on non-sorted collections.
>>>
>>> Why? what would be the reason not to use sortBlock: for others?
>>
>> The intention is different. #sortBlock: tells a collection to maintain
>> itself as sorted even after additions and deletions. This message is not
>> appropriate for collections that do not have that ability.
>>
>> #sortBlock: is not the best name for this functionality, but I think
>> it's bad to use #sortBlock: with a different meaning.
>
> I agree :)
> Now SortedCollection should understand sort too which uses sortBlock:
> My main concern is polymorphism between collection which are nearly the same!

> On Thu, Dec 24, 2009 at 12:19 AM, Stéphane Ducasse
> <[hidden email]> wrote:
>>> #sortBlock: is defined by ANSI on SortedCollection as an accessor and
>>>>> an instance creation method. That's what it sounds like and shouldn't
>>>>> be implemented on non-sorted collections.
>>>>
>>>> Why? what would be the reason not to use sortBlock: for others?
>>>
>>> The intention is different. #sortBlock: tells a collection to maintain
>>> itself as sorted even after additions and deletions. This message is not
>>> appropriate for collections that do not have that ability.
>>>
>>> #sortBlock: is not the best name for this functionality, but I think
>>> it's bad to use #sortBlock: with a different meaning.
>>
>> I agree :)
>> Now SortedCollection should understand sort too which uses sortBlock:
>> My main concern is polymorphism between collection which are nearly the same!
>
> #sortBlock: is an accessor for the sortBlock instance variable on
> SortedCollection. It makes no sense for a collection that doesn't have
> that instance variable to have that accessor.

>
> On Dec 24, 2009, at 10:00 AM, Julian Fitzell wrote:
>
>> On Thu, Dec 24, 2009 at 12:19 AM, Stéphane Ducasse
>> <[hidden email]> wrote:
>>>> #sortBlock: is defined by ANSI on SortedCollection as an accessor and
>>>>>> an instance creation method. That's what it sounds like and shouldn't
>>>>>> be implemented on non-sorted collections.
>>>>>
>>>>> Why? what would be the reason not to use sortBlock: for others?
>>>>
>>>> The intention is different. #sortBlock: tells a collection to maintain
>>>> itself as sorted even after additions and deletions. This message is not
>>>> appropriate for collections that do not have that ability.
>>>>
>>>> #sortBlock: is not the best name for this functionality, but I think
>>>> it's bad to use #sortBlock: with a different meaning.
>>>
>>> I agree :)
>>> Now SortedCollection should understand sort too which uses sortBlock:
>>> My main concern is polymorphism between collection which are nearly the same!
>>
>> #sortBlock: is an accessor for the sortBlock instance variable on
>> SortedCollection. It makes no sense for a collection that doesn't have
>> that instance variable to have that accessor.
>
> did I say that? I do not think so. I'm not that idiot.
> No I say that SortedCollection should understand sort:

>>>>> #sortBlock: is defined by ANSI on SortedCollection as an accessor and
>>>>>>> an instance creation method. That's what it sounds like and shouldn't
>>>>>>> be implemented on non-sorted collections.
>>>>>>
>>>>>> Why? what would be the reason not to use sortBlock: for others?
>>>>>
>>>>> The intention is different. #sortBlock: tells a collection to maintain
>>>>> itself as sorted even after additions and deletions. This message is not
>>>>> appropriate for collections that do not have that ability.
>>>>>
>>>>> #sortBlock: is not the best name for this functionality, but I think
>>>>> it's bad to use #sortBlock: with a different meaning.
>>>>
>>>> I agree :)
>>>> Now SortedCollection should understand sort too which uses sortBlock:
>>>> My main concern is polymorphism between collection which are nearly the same!
>>>
>>> #sortBlock: is an accessor for the sortBlock instance variable on
>>> SortedCollection. It makes no sense for a collection that doesn't have
>>> that instance variable to have that accessor.
>>
>> did I say that? I do not think so. I'm not that idiot.
>> No I say that SortedCollection should understand sort:
>
> Ah, apologies - I misunderstood what you were saying (I was a little
> surprised that you would be arguing what I thought you were arguing :)
> ).
>
> Julian
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> ouf honor is safe :)
> So try to convince VA to do a better job than ANSI.
> because with sort: polymorph and sorted (suboptimal but ok) we can have a better solution
>
> Stef
>
>
>>>>>> #sortBlock: is defined by ANSI on SortedCollection as an accessor and
>>>>>>>> an instance creation method. That's what it sounds like and shouldn't
>>>>>>>> be implemented on non-sorted collections.
>>>>>>>
>>>>>>> Why? what would be the reason not to use sortBlock: for others?
>>>>>>
>>>>>> The intention is different. #sortBlock: tells a collection to maintain
>>>>>> itself as sorted even after additions and deletions. This message is not
>>>>>> appropriate for collections that do not have that ability.
>>>>>>
>>>>>> #sortBlock: is not the best name for this functionality, but I think
>>>>>> it's bad to use #sortBlock: with a different meaning.
>>>>>
>>>>> I agree :)
>>>>> Now SortedCollection should understand sort too which uses sortBlock:
>>>>> My main concern is polymorphism between collection which are nearly the same!
>>>>
>>>> #sortBlock: is an accessor for the sortBlock instance variable on
>>>> SortedCollection. It makes no sense for a collection that doesn't have
>>>> that instance variable to have that accessor.
>>>
>>> did I say that? I do not think so. I'm not that idiot.
>>> No I say that SortedCollection should understand sort:
>>
>> Ah, apologies - I misunderstood what you were saying (I was a little
>> surprised that you would be arguing what I thought you were arguing :)
>> ).
>>
>> Julian
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>
> We might require a special implementation for SortedCollection,
> alright. I don't see why that would be a problem for them.
>
> Julian
>
> On Fri, Dec 25, 2009 at 1:08 AM, Stéphane Ducasse
> <[hidden email]> wrote:
>> ouf honor is safe :)
>> So try to convince VA to do a better job than ANSI.
>> because with sort: polymorph and sorted (suboptimal but ok) we can have a better solution
>>
>> Stef
>>
>>
>>>>>>> #sortBlock: is defined by ANSI on SortedCollection as an accessor and
>>>>>>>>> an instance creation method. That's what it sounds like and shouldn't
>>>>>>>>> be implemented on non-sorted collections.
>>>>>>>>
>>>>>>>> Why? what would be the reason not to use sortBlock: for others?
>>>>>>>
>>>>>>> The intention is different. #sortBlock: tells a collection to maintain
>>>>>>> itself as sorted even after additions and deletions. This message is not
>>>>>>> appropriate for collections that do not have that ability.
>>>>>>>
>>>>>>> #sortBlock: is not the best name for this functionality, but I think
>>>>>>> it's bad to use #sortBlock: with a different meaning.
>>>>>>
>>>>>> I agree :)
>>>>>> Now SortedCollection should understand sort too which uses sortBlock:
>>>>>> My main concern is polymorphism between collection which are nearly the same!
>>>>>
>>>>> #sortBlock: is an accessor for the sortBlock instance variable on
>>>>> SortedCollection. It makes no sense for a collection that doesn't have
>>>>> that instance variable to have that accessor.
>>>>
>>>> did I say that? I do not think so. I'm not that idiot.
>>>> No I say that SortedCollection should understand sort:
>>>
>>> Ah, apologies - I misunderstood what you were saying (I was a little
>>> surprised that you would be arguing what I thought you were arguing :)
>>> ).
>>>
>>> Julian
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project