On Tue, 19 Feb 2008 19:36:55 +0100, Igor Stasenko wrote:

> On 19/02/2008, goran at krampe.se <goran at krampe.se> wrote:
>> Hi!
>>
>> Reinout Heeck <reinz at desk.org> wrote:
>> > goran at krampe.se wrote:
>> > > The *normal* way people usually do it thoiugh is to *not depend on  
>> the
>> > > identity* of the Collection - different objects should typically not
>> > > share the same Collection. And if you don't share - then the easy  
>> way
>> > > out is to just do:
>> > >
>> > >     myCollection := OrderedCollection new "or whatever class you  
>> use"
>> > >
>> > > ...in order to empty it.
>> >
>> >
>> > A word of caution: identity should be preserved in the 'normal' case,
>>
>> I agree. While I still think relying too much on identities is a
>> dangerous practice.
>>
>> > replacing with another collection should be regarded as the  
>> exceptional
>> > case. Your assertion that "different objects should typically not  
>> share
>> > the same Collection." is only valid in limited cases.
>>
>> Well, I still stand by it as a general "nice rule". :)
>>
>> > I'm talking from my experience with building mvc-based apps on
>> > VisualWorks. Code needs to be decoupled, ie 'model' objects and
>> > collections should not know about the UI's that are coupled to them,
>> > this is achieved with the various dependency mechanisms available in  
>> VW.
>>
>> I know, I used VW back in the 2.5-3.x days and while I first thought the
>> adapter-frenzy was cool I later also started thinking it was
>> over-engineered as hell. ;)
>>
>> > Changing identity of the collections will break this paradigm big time
>> > (regardless of whether the dependents are managed in a global  
>> dictionary
>> > or by the collection itself).
>>
>> Yes, if your adapters/UI components etc cling onto the collections
>> themselves, then yes, you will be bitten big time. I still think that
>> paradigm is fishy - but again, I only presented the way people
>> *typically* go about this thing - I still of course would like to
>> preserve identity and introduce #removeAll. It is better in all
>> respects.
>>
>> If the *intent* is to "remove all elements" - then the message should
>> state exactly that intent. Doing stuff like "aColl copy do: [:each |
>> aColl remove: each]" is just plain dumb and silly, though it would
>> probably qualify as a default implementation in class Collection. :)
>>
> It can be even shorter then:
>
> Collection>>removeAll
>    self removeAll: self copy

Unless you stop people from overriding #copy and instead perform an  
almost-very-deep-copy: thumbs down; this is about removal, not about  
duplicating.

>
>>
>>
>
>