Splitting Set and Dictionary

>
> Loading the packages will change previous behavior in some cases:
>
> - Dictionary >> #copyWithout: doesn't raise an error anymore. Example:
>   (Dictionary newFrom: { #foo -> 1. #bar -> 2 }) copyWithout: 1
>     ==> a Dictionary(#bar->2 ) (instead of an error)
> - No more asymmetric set-dictionary equality. Example:
>   #(1 2) asSet = (Dictionary newFrom: { #foo -> 1. #bar -> 2 })
>     ==> false (instead of true)
>   (Dictionary newFrom: { #foo -> 1. #bar -> 2 }) = #(1 2) asSet
>     ==> false (same as before)
>
> Cheers,
> Levente
>
>

> Hi,
>
> I uploaded 3 packages to the inbox which add a common superclass to Set
> and Dictionary. The suggested load order is:
> 1. Collections-ul.198
> 2. Collections-ul.199
> 3. KernelTests-ul.110
>
> Loading the packages will change previous behavior in some cases:
>
> - Dictionary >> #copyWithout: doesn't raise an error anymore. Example:
>    (Dictionary newFrom: { #foo -> 1. #bar -> 2 }) copyWithout: 1
>      ==> a Dictionary(#bar->2 ) (instead of an error)
> - No more asymmetric set-dictionary equality. Example:
>    #(1 2) asSet = (Dictionary newFrom: { #foo -> 1. #bar -> 2 })
>      ==> false (instead of true)
>    (Dictionary newFrom: { #foo -> 1. #bar -> 2 }) = #(1 2) asSet
>      ==> false (same as before)
>
> Cheers,
> Levente
>

> Hi,
>
> I uploaded 3 packages to the inbox which add a common superclass to Set and
> Dictionary. The suggested load order is:
> 1. Collections-ul.198
> 2. Collections-ul.199
> 3. KernelTests-ul.110
>
> Loading the packages will change previous behavior in some cases:
>
> - Dictionary >> #copyWithout: doesn't raise an error anymore. Example:
>  (Dictionary newFrom: { #foo -> 1. #bar -> 2 }) copyWithout: 1
>    ==> a Dictionary(#bar->2 ) (instead of an error)
> - No more asymmetric set-dictionary equality. Example:
>  #(1 2) asSet = (Dictionary newFrom: { #foo -> 1. #bar -> 2 })
>    ==> false (instead of true)
>  (Dictionary newFrom: { #foo -> 1. #bar -> 2 }) = #(1 2) asSet
>    ==> false (same as before)
>
> Cheers,
> Levente
>
>

> :-)
>
> Cheers,
>  - Andreas
>
>>
>> Loading the packages will change previous behavior in some cases:
>>
>> - Dictionary >> #copyWithout: doesn't raise an error anymore. Example:
>>   (Dictionary newFrom: { #foo -> 1. #bar -> 2 }) copyWithout: 1
>>     ==> a Dictionary(#bar->2 ) (instead of an error)
>> - No more asymmetric set-dictionary equality. Example:
>>   #(1 2) asSet = (Dictionary newFrom: { #foo -> 1. #bar -> 2 })
>>     ==> false (instead of true)
>>   (Dictionary newFrom: { #foo -> 1. #bar -> 2 }) = #(1 2) asSet
>>     ==> false (same as before)
>>
>> Cheers,
>> Levente
>>
>>
>
>
>

> On Fri, 20 Nov 2009, Igor Stasenko wrote:
>
>> Few comments.
>
> Thanks, they are always welcome.
>
>> HashedCollection is hardly abstract, because it implies how to use the
>> state (tally, array) in
>> specific way. But i think this is fine.
>>
>
> It's abstract because it's not complete and no instrances of it should be
> created. I don't like the idea that abstract classes can't have state or
> can't have implementation details.
>
>> A #like: method , IMO first should appear in Set, since its completely
>> meaningless for Dictionary.
>>
>
> I agree. I wanted to do the split with minimal changes in behavior.
>
>> A Set>>collect: and Set>>select: using different ways to initialize
>> new collection.
>> One is:
>> newSet := Set new: self size.
>
> It's an old story why Set is directly referenced here. It's the least wrong
> choice. I think a commend should be added there.
>

>> another is:
>> newCollection := self copyEmpty.
>
> It's a nice trick to use copyEmpty here by Nicolas IIRC. It enables
> instances of Set's subclasses to properly initialize their instance
> variables (like PluggableSet or KeyedSet).
>
> Cheers,
> Levente
>
>>
>> i think they should use 'self species' .
>>
>> 2009/11/19 Levente Uzonyi <[hidden email]>:
>>>
>>> Hi,
>>>
>>> I uploaded 3 packages to the inbox which add a common superclass to Set
>>> and
>>> Dictionary. The suggested load order is:
>>> 1. Collections-ul.198
>>> 2. Collections-ul.199
>>> 3. KernelTests-ul.110
>>>
>>> Loading the packages will change previous behavior in some cases:
>>>
>>> - Dictionary >> #copyWithout: doesn't raise an error anymore. Example:
>>>  (Dictionary newFrom: { #foo -> 1. #bar -> 2 }) copyWithout: 1
>>>    ==> a Dictionary(#bar->2 ) (instead of an error)
>>> - No more asymmetric set-dictionary equality. Example:
>>>  #(1 2) asSet = (Dictionary newFrom: { #foo -> 1. #bar -> 2 })
>>>    ==> false (instead of true)
>>>  (Dictionary newFrom: { #foo -> 1. #bar -> 2 }) = #(1 2) asSet
>>>    ==> false (same as before)
>>>
>>> Cheers,
>>> Levente
>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>
>
>

> Hi,
>
> I uploaded a proposal to the inbox (Collections-ul.205) which tries to
> solve the issues with #collect:.
> The idea is to let #collect: use #species and add two new interface
> methods to the Collections hierarchy to handle exceptional cases. The
> two methods are: #collect:into: and #collect:as:. Both work like
> #collect:, but #collect:into: expects a Collection as it's second
> argument and collects the values into that collection. #collect:as:
> expects a subclass of Collection and returns an instance filled with the
> collected values.
>
> A few examples demonstrate possible usage:
> (1 to: 9) collect: [ :each | each asString first ] as: ByteString
>   ==> '123456789'.
> (1 to: 9) collect: [ :each | each \\ 5 ] as: Set
>   ==>  a Set(0 1 2 3 4)
> (1 to: 9) asSet collect: [ :each | 10 - each ] as: SortedCollection
>   ==> a SortedCollection(1 2 3 4 5 6 7 8 9)
> #(1 5 2 4 3) collect: #yourself as: Heap
>   ==> a Heap(1 3 2 5 4)
> (Dictionary newFrom: { #one -> 1. #two -> 2 }) collect: #squared as:
> IdentityDictionary
>   ==> an IdentityDictionary(#one->1 #two->4 ).
> (Dictionary newFrom: { #one -> 1. #two -> 2 }) collect: #squared as: Array
>   ==> #(4 1)
> (1 to: 10) collect: [ :each | each > 1 and: [ each isPrime ] ] as:
> Dictionary
>   ==> a Dictionary(1->false 2->true 3->true 4->false 5->true 6->false
> 7->true 8->false 9->false 10->false )
> #(20 30 40) collect: [ :each | each // 10 ] as: IdentityDictionary
>   ==> an IdentityDictionary(1->2 2->3 3->4 )
>
> a := #(1 2 3). a collect: #squared into: a
>   ==> #(1 4 9).
>
> Even #collect: could be implemented as: ^self collect: aBlock as: self
> species.
> Of course there are combinations which don't work, but i think those
> don't make much sense. For example you can't collect a Set into a
> Dictionary.
>
> What do you think?
>
> Cheers,
> Levente
>
>> On Fri, 20 Nov 2009, Igor Stasenko wrote:
>>
>>> hmm.. WeakSet/IdentitySet>>collect: returning an instance of Set?
>
>

> On Sat, 21 Nov 2009, Andreas Raab wrote:
>
>>> What do you think?
>>
>> I like it a lot. It allows us to be explicit in cases where we care and
>> consequently give us room to change the default if we think it's not all
>> that useful.
>
> Should we keep the current behavior of Set >> #collect: to return a Set even
> in subclasses (IdentitySet, PluggableSet, etc)?
>