Post #7,855
9/6/01 3:55:16 PM
|
Smalltalk Question
What is a "real" Smalltalk way to move some elements to another collection. As in, I need the elements of collection to be split into 2 subset: one stays, another goes to a different collection.
RIght now I do it like this:
|collToStay collToGo|
collToStay := coll select: [ : each | each stays].
collToGo := coll select: [ : each | each stays not].
coll := collToStay.
self sendForth: collToGo.
Is there a better way?
|
Post #7,889
9/6/01 10:51:28 PM
|
Isn't there a reject message?
So you could do:
|collToGo|
collToGo := coll reject: [ : each | each stays].
coll := coll select: [ : each | each stays].
self sendForth: collToGo.
... but you're probably looking for something to send two collections two ways simultaneously, aren't you?
Wade.
"All around me are nothing but fakes
Come with me on the biggest fake of all!"
|
Post #7,924
9/7/01 10:26:43 AM
|
Re: Isn't there a reject message?
yeah, but it's still 2 messages...
Would be more elegant to have a "split:" mesage: things that are removed get gathered in another collection.
|
Post #7,937
9/7/01 12:53:55 PM
|
Yes
use #removeAllSuchThat: aBlock
Like most Smalltalk collection methods, it returns something useful. In this case, it removes all objects for which aBlock is true; it also returns a collection of what was removed
======================
|colToGo |
colToGo := coll removeAllSuchThat: [: each | each stays not]
======================
This is present in VisualWorks; I haven't checked other implemtations. If not available on your platform, I can post the code for the method
Take care,
Jay O'Connor
"Going places unmapped
to do things unplanned
to people unsuspecting"
|
Post #7,938
9/7/01 1:05:39 PM
|
Yes... Yes! Yes!
:)
Thanks for the hint.
I am using VisualWorks non-commercial.
|
Post #7,941
9/7/01 2:11:41 PM
|
So how's it done?
I can see the stripped members being sent back as the result of the function. The only way I can see that the function would strip the original collection is if it uses a become: method. So is that how it's done?
|
Post #7,942
9/7/01 2:45:51 PM
|
I don't get it
It just loops through itself and anything that matches the block gets added to a temp collection to be returned and removed
Do you mean how do you remove from within a loop? How do you change a collection while iterating over the collection? The loop internal to the method actually sets up an loop over the indices of the collection. The element to be removed used removed using it's index (#removeByIndex: ) #removeByIndex: just goes from the given index to end, scooting every element up one position and then cutting off the last element
Jay O'Connor
"Going places unmapped
to do things unplanned
to people unsuspecting"
|
Post #7,954
9/7/01 4:12:39 PM
|
Never mind...
...been studying too many functional languages, and for some reason I keep thinking that collections are immutable objects in ST. Must go back and study Squeak some more.
BTW, the message that you gave for VW doesn't seem to be standard in Squeak.
|
Post #7,987
9/8/01 3:54:49 AM
|
heh heh heh
I have that problem in Icon, too. Collections and variables are generally intuitively mutable wherever you put them :-). Sometimes makes for very very elegant code.
Wade.
"All around me are nothing but fakes
Come with me on the biggest fake of all!"
|
Post #7,995
9/8/01 11:18:30 AM
|
Standard or not?
Did you look in List or OrderedCollection? That's where it is.
|
Post #7,930
9/7/01 11:26:29 AM
|
Not aware
Not a ST expert by any means - but a couple of obvservations. First, you could save yourself a local variable if you want to just reallocate the coll object in place (see bellow). Second, you have to be careful that the "coll" variable is shared in all usages - the coll variable points to a new object as a result of the operation, but any other variables that pointed to the previous collection object still point to the object originally pointed to by coll. IOW, you end up with three objects as a result of the operation - one of which will be garbage collected if there are no other references holding on to it.
The only other thought that comes to mind is that ST only allows one value to be returned by a function. So if you wanted two collections to be returned, you'd have to have return a collection that contained both collections. That would probably be the more correct ST solution since it doesn't touch the original collection in the logic (i.e. rely on a variable being invisibly passed to the method).
|collToGo|
collToGo := coll select: [ : each | each stays not].
coll := coll select: [ : each | each stays].
self sendForth: collToGo.
|
Post #7,939
9/7/01 1:10:29 PM
|
Re: Not aware
coll is a member variable in the class instance. It never escapes the instance - no methods return it. I am aware of having 3 objects at some point, and that's one of the reasons I am looking for a better solution.
|
Post #8,044
9/9/01 6:43:54 AM
|
Speaking of smalltalk
Is there a good book that would help me wrap my mind around it?
With all respect to smalltalk, everytime I see code, I get about two steps into it and then my mind turns into a pretzel. My first language was Fortran. My first language at work was C. I've done some Turbo Pascal and more recently C++ and Java, but Smalltalk..... BONK
French Zombies are zapping me with lasers!
|
Post #8,701
9/12/01 5:36:31 PM
|
Re: Speaking of smalltalk
My first language was Fortran.
Oh your poor thing! There's your problem for sure.
The syntax mind bender is a prejudice you've formed over time.
You're used to seeing stuff like HashMapAdd(map,key,value);
Which is a really sucky syntax - even worse are the way javap prints out
the prototypes as
void java.util.HashMap.add(java.lang.Object,java.lang.Object) and you have
no idea which argument which.
Smalltalk puts arguments within the selectors (method names basically).
dictionary at: aKey put: anObject
the method name is at:put: or as more commonly written #at:put:
Anyhow, the David N Smith book is pretty good in general. The Ken Howard book Developers Guide to Visualworks is really good if you're using Visualworks. The Art and Science of Smalltalk (forget the author offhand) is also quite decent.
|
Post #8,892
9/13/01 1:24:32 PM
|
Re: Speaking of smalltalk
Try this link: [link|http://wiki.cs.uiuc.edu/VisualWorks/Joy+of+Smalltalk|http://wiki.cs.uiuc...of+Smalltalk]
I don't know if it's the best book, but it's online and it's free. I actually liked it.
But, when you want to wrap your mind around the relationship between Class and Object and Metaclass and Behavior.... You are on your own. Wrack your brain til you get it.
|
Post #8,897
9/13/01 1:35:53 PM
|
Fortunately
But, when you want to wrap your mind around the relationship between Class and Object and Metaclass and Behavior.... You are on your own. Wrack your brain til you get it
That's more a curiosity for those inquisitive on 'how things work' then required knowledge for most programming
Jay O'Connor
"Going places unmapped
to do things unplanned
to people unsuspecting"
|
Post #8,921
9/13/01 2:34:53 PM
|
I don't think _I_ could do without.
I really can't work if there is any magic involved ( above the level of hardware :) )
|
