Hi! CCing squeak-dev because I would like to see this fixed. :) "Ron Teitelbaum" <[hidden email]> wrote: > Hi Sophie, > > aCollection copy do: [:anElement | > aCollection remove: anElement > ]. > > Why copy? If you start removing items from the collection, increasing the > index will cause you to skip elements. Because modifying the collection while iterating over the same is not safe generally. The above idiom is "known" - but of course it sucks. :) I advocated to add a #removeAll message in the protocol of Collection and then implement it in subclasses using efficient variants a looooong while back but it never got accepted. The climate today for such a change is much more... "pragmatic" I think and hope. So we should simply add it! 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. But in low level code it would be nice to have the #removeAll method because it can be very efficiently implemented in different subclasses and would avoid reallocations etc. regards, Göran |
On 19/02/2008, [hidden email] <[hidden email]> wrote:
> > Hi! > > CCing squeak-dev because I would like to see this fixed. :) > > "Ron Teitelbaum" <[hidden email]> wrote: > > Hi Sophie, > > > > aCollection copy do: [:anElement | > > aCollection remove: anElement > > ]. > > > > Why copy? If you start removing items from the collection, increasing the > > index will cause you to skip elements. > > Because modifying the collection while iterating over the same is not > safe generally. The above idiom is "known" - but of course it sucks. :) > > I advocated to add a #removeAll message in the protocol of Collection > and then implement it in subclasses using efficient variants a looooong > while back but it never got accepted. The climate today for such a > change is much more... "pragmatic" I think and hope. So we should simply > add it! > > 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. > > But in low level code it would be nice to have the #removeAll method > because it can be very efficiently implemented in different subclasses > and would avoid reallocations etc. > Arrays don't have ways to change a number of elements they contain. All you can do is to make a copy of it with changed collection of elements during copy, but that would be another array, not original one. Oh, but yes, there already different #removeXXX methods in Collection class. This method will have same problems with Array/Interval as this ones. A most 'pragmatic' change in this way would be to insert a subclass of Collection like DynamicCollection and move all methods which may affect the number of elements to this class. Then all collection types, which can dynamically change the number of elements should subclass from it. But we are all know, that such changes will never appear regardless how much pragmatic they are. ;) > regards, Göran > -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Göran Krampe
[hidden email] 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, 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. 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. 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). As to the implementation of #removeAll on non-growable collections: follow whatever pattern the squeak library uses for other messages that alter the size (#add:, #remove:,...). In VW the idiom is to call #shouldNotImplement. Cheers, R - |
Hi!
Reinout Heeck <[hidden email]> wrote: > [hidden email] 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 |
Hi all!
Ok, since this was discussed AT PAINFULLY GREAT LENGTH back in aug/sept 2002 I just wanted to give you some reading on the subject at hand. Don't *ever* presume the issue you are bringing attention to hasn't been argued to death already :) :) Threads of discussions related to this from 2002: http://lists.squeakfoundation.org/pipermail/squeak-dev/2002-August/04315 7.html http://lists.squeakfoundation.org/pipermail/squeak-dev/2002-September/04 3926.html http://lists.squeakfoundation.org/pipermail/squeak-dev/2002-September/04 3928.html Especially Richard O Keefe did an awesome job back then IIRC. Now, if those threads will not exhaust you completely :) - then feel free to hack up a changeset that is a conclusion of all findings in there. :) regards, Göran |
In reply to this post by Göran Krampe
On 19/02/2008, [hidden email] <[hidden email]> wrote:
> Hi! > > Reinout Heeck <[hidden email]> wrote: > > [hidden email] 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. :) > Collection>>removeAll self removeAll: self copy > regards, Göran > > -- Best regards, Igor Stasenko AKA sig. |
On Tue, 19 Feb 2008 19:36:55 +0100, Igor Stasenko wrote:
> On 19/02/2008, [hidden email] <[hidden email]> wrote: >> Hi! >> >> Reinout Heeck <[hidden email]> wrote: >> > [hidden email] 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. > >> >> > > |
In reply to this post by Igor Stasenko
Would nilFields work as well?
Sean -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko Sent: Tuesday, February 19, 2008 11:37 AM To: The general-purpose Squeak developers list Subject: Re: [Newbies] How to empty a collection? On 19/02/2008, [hidden email] <[hidden email]> wrote: > Hi! > > Reinout Heeck <[hidden email]> wrote: > > [hidden email] 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. :) > Collection>>removeAll self removeAll: self copy > regards, Göran > > -- Best regards, Igor Stasenko AKA sig. |
Free forum by Nabble | Edit this page |