I can't find the correct way to think about #= message for collections...
For example, Dictionary use Set>>= that ignores keys.
Bag, has not implemented the message.
All the SequenceableCollection family seems to be good (IMHO).
There exists a message that compares the elements of a collection with another ignoring the collection species?
TIA,
Diego Gomez Deck
I can't find the correct way to think about #= message for collections...
For example, Dictionary use Set>>= that ignores keys.
Bag, has not implemented the message.
All the SequenceableCollection family seems to be good (IMHO).
There exists a message that compares the elements of a collection with another ignoring the collection species?
TIA,
Diego Gomez Deck
I can 'fix/complete' the Collection tree, but I'd like to know the community thinking....
My idea is that #= answer with true when the two collection have the same specie, the same contents, the same order, the same keys and the same occurrences.
We need some extras messages to handle the other ways to compare collection:
#sameContent: ignores the specie, ignores the order, ignores the keys and ignores the occurrences. #exactContent: ignores the specie, ignores the order, ignores the keys but care of the occurrences. #sameKeys: the two collection has the same Set of keys, don't care about the specie.
Some examples:
| a d d2 b | a := {1. 2. 3}. d := Dictionary new. d at:'someKey' put:1. d at:'otherKey' put:2. d at:'justOtherKey' put:3. b add:1. b add:1. b add:2. b add:3.
a sameContent: d -> true a sameContent: b -> true
a exactContent: d -> true a exactContent: b -> false
d2 := Dictionary new. d2 at:1 put:1. d2 at:2 put:2. d2 at:3 put:3.
d2 sameKeys:a -> true "the array has integer keys"
What do you think about this??
TIA,
Diego Gomez Deck
For example, Dictionary use Set>>= that ignores keys.
This looks like an accident, to me.
Lex
Diego Gomez Deck DiegoGomezDeck@ConsultAr.com wrote:
I can 'fix/complete' the Collection tree, but I'd like to know the community thinking....
My idea is that #= answer with true when the two collection have the same specie, the same contents, the same order, the same keys and the same occurrences.
Sounds good, although some of it will depend on the collection type. Two Sets can have the same elements but different #do: orderings because of the order the elements were added, but it seems like they should still be #=.
Also, it really seems like the two collections should have the same *class* -- (1 to: 4) isn't really the same as #(1 2 3 4).
We need some extras messages to handle the other ways to compare collection:
#sameContent: ignores the specie, ignores the order, ignores the keys and ignores the occurrences. #exactContent: ignores the specie, ignores the order, ignores the keys but care of the occurrences. #sameKeys: the two collection has the same Set of keys, don't care about the specie.
I agree that comparing collections has several interpreterations, but I'm not sure what the exact list should be. Note that each of these can already be done with only a little more work:
sameContent -> x asSet = y asSet exactContent -> x asBag = y asBag samKeys -> x keys asSet = y keys asSet
And I'm not so sure the list of variations is going to end any time soon. I'm not sure they won't, to be fair. :) But how about #= versus #== on the elements, for example?
Until there's reason to believe that the list of types of comparisons has been sorted out, I'd lean towards letting people type out what they mean explicitly.
All MHO. Others have probably thought about this more than either of us -- collections are a pretty neat part of Smalltalk!
Lex
"Joshua 'Schwa' Gargus" schwa@cc.gatech.edu wrote:
Also, it really seems like the two collections should have the same *class* -- (1 to: 4) isn't really the same as #(1 2 3 4).
I don't know about that, Lex. What do you mean by "really the same"? Not identity; we already have == for that. Definition, please :-) Keep in mind that Whatever you come up should be at least as useful as "contains the same elements".
No prob: "can be used in place of". Intervals cannot be modified in place, while arrays can.
Then again, it's worth staying in sync with #foo vs. 'foo', and in fact those two objects are considered #= even though one is mutable and the other is not.
Oh well, I guess I'm okay with "same species" after all.
Here's a case that seems similar to me: should 5 = 5.0 be false because the numbers are of different classes?
Good example! Overall, "same as" seem to be a vague concept, and we'll just have to pick for each kind of element what it means. For numbers, allowing floats to equal integers is fine.
Lex
squeak-dev@lists.squeakfoundation.org
-
Diego Gomez Deck -
Lex Spoon