Hi!
Reinout Heeck reinz@desk.org wrote:
goran@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. :)
regards, Göran