Splitting Set and Dictionary

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Splitting Set and Dictionary

Levente Uzonyi-2
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

Reply | Threaded
Open this post in threaded view
|

Re: Splitting Set and Dictionary

Andreas.Raab
Levente Uzonyi wrote:
> 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

Very nice, very nice. The tests pass too which leaves me with one
nitpick only: Can I have a class comment for HashedCollection please?
Pretty please? :-)

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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Splitting Set and Dictionary

Martin Kuball
In reply to this post by Levente Uzonyi-2
Am Thursday 19 November 2009 schrieb Levente Uzonyi:

> 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
>

I wonder if we could have a mapped collection that preserves the order in
which elements are added to it. Would be nice to have this in the base
image. I used SkipList for this in older images. But since the class is
gone there is kind of a hole here.

Martin



Reply | Threaded
Open this post in threaded view
|

Squeaksource.com project missing (was Re: Splitting Set and Dictionary)

Ken Causey-3
On Thu, 2009-11-19 at 20:57 +0100, Martin Kuball wrote:
> I wonder if we could have a mapped collection that preserves the order in
> which elements are added to it. Would be nice to have this in the base
> image. I used SkipList for this in older images. But since the class is
> gone there is kind of a hole here.
>
> Martin

You may already be aware but SkipList is not completely gone, it can
still be found at

Argh....

I was just going to find the URL for the squeaksource.com repository I
setup for SkipList and it is now missing.

Well, hopefully in time it will appear back at

http://www.squeaksource.com/skiplists.html

before long.

Also, maybe this package could become a blessed official contributed
package although it has licensing problems.

Ken



signature.asc (197 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Squeaksource.com project missing

Randal L. Schwartz
>>>>> "Ken" == Ken Causey <[hidden email]> writes:

Ken> You may already be aware but SkipList is not completely gone, it can
Ken> still be found at

Ken> Argh....

Ken> I was just going to find the URL for the squeaksource.com repository I
Ken> setup for SkipList and it is now missing.

Do we need a skiptracer to find it? :)

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Reply | Threaded
Open this post in threaded view
|

Re: Splitting Set and Dictionary

Igor Stasenko
In reply to this post by Levente Uzonyi-2
Few comments.
HashedCollection is hardly abstract, because it implies how to use the
state (tally, array) in
specific way. But i think this is fine.

A #like: method , IMO first should appear in Set, since its completely
meaningless for Dictionary.

A Set>>collect: and Set>>select: using different ways to initialize
new collection.
One is:
newSet := Set new: self size.
another is:
newCollection := self copyEmpty.

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.

Reply | Threaded
Open this post in threaded view
|

Re: Re: Splitting Set and Dictionary

Levente Uzonyi-2
In reply to this post by Andreas.Raab
On Wed, 18 Nov 2009, Andreas Raab wrote:

> Levente Uzonyi wrote:
>> 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
>
> Very nice, very nice. The tests pass too which leaves me with one nitpick
> only: Can I have a class comment for HashedCollection please? Pretty please?

Thanks. Sure, fixing class comments is on my "todo list", they were
already obsolete.

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
>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Splitting Set and Dictionary

Levente Uzonyi-2
In reply to this post by Igor Stasenko
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.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Splitting Set and Dictionary

Igor Stasenko
2009/11/20 Levente Uzonyi <[hidden email]>:

> 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.
>

hmm.. WeakSet/IdentitySet>>collect: returning an instance of Set?


>> 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.
>>
>
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Splitting Set and Dictionary

Levente Uzonyi-2
On Fri, 20 Nov 2009, Igor Stasenko wrote:

> 2009/11/20 Levente Uzonyi <[hidden email]>:
>> 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.
>>
>
> hmm.. WeakSet/IdentitySet>>collect: returning an instance of Set?
Imagine you have an IdentitySet or WeakSet with classes in it. And
let's collect their name as Strings. What do you expect to get? An
IdentitySet that returns false to any outer #includes: send? Or an empty
WeakSet? I doubt that. But this has been discussed long time ago and
multiple times here on the list. I guess one of the discussions starts here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-February/052840.html

Levente

> >
>>> 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.
>>>
>>
>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

Reply | Threaded
Open this post in threaded view
|

Issues with #collect: (Was: Re: Splitting Set and Dictionary)

Levente Uzonyi-2
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?

Reply | Threaded
Open this post in threaded view
|

Re: Issues with #collect: (Was: Re: Splitting Set and Dictionary)

Andreas.Raab
 > 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.

Cheers,
   - Andreas

Levente Uzonyi wrote:

> 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?
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Squeaksource.com project missing (was Re: Splitting Set and Dictionary)

Ken Causey-3
In reply to this post by Ken Causey-3
On Sat, 2009-11-21 at 21:45 +0100, Martin Kuball wrote:

> Am Thursday 19 November 2009 schrieben Sie:
> > On Thu, 2009-11-19 at 20:57 +0100, Martin Kuball wrote:
> > > I wonder if we could have a mapped collection that preserves the order
> > > in which elements are added to it. Would be nice to have this in the
> > > base image. I used SkipList for this in older images. But since the
> > > class is gone there is kind of a hole here.
> > >
> > > Martin
> >
> > You may already be aware but SkipList is not completely gone, it can
> > still be found at
>
> Well, I did not had a look. But I was confident that it would be there if I
> really needed it. The question ist if I depend on SkipList in a program
> what happens if people install it from SqueakMap or Universe?
I'm sorry, install which?  Your package or SkipList?  If you mean the
first are you asking about how to handle dependencies?  If the second
are you concerned about updates to the package breaking your code?

> > Argh....
> >
> > I was just going to find the URL for the squeaksource.com repository I
> > setup for SkipList and it is now missing.
> >
> > Well, hopefully in time it will appear back at
> >
> > http://www.squeaksource.com/skiplists.html
> >
> > before long.
> >
> > Also, maybe this package could become a blessed official contributed
> > package although it has licensing problems.
>
> Would be nice.
>
> I remember that Andreas some time ago asked about this. He was pointed to a
> class that maintained the order of the keys in an array as additional
> instance var.
>
> Martin
The idea of external packages distributed with a release, as
semi-official 'known to work' external packages has been discussed both
by the Squeak Oversight Board and recently Andreas tried to start a
discussion on squeak-dev about it because it needs to be supported by a
package system like SqueakMap or Universes but neither quite fits the
bill and we hope to find someone interested in improving the situation.

In any case, find attached the extracted SkipList code (at least the
most recent I can find, I have this feeling that someone contributed at
least one new version on the SqueakSource site but can't quite remember
who).  I have not tested this since I extracted it and it is possible
that recent collection changes have broken it.

This may illustrate one of your concerns but it's a concern that any
external package has, ultimately those interested in a piece of code
have to be responsible for maintaining it.  Pushing it into the core
image may seem like a solution but it's really not, witness all the
crufty not recently used, probably not working code in Squeak today.  I
have to admit that by and large my interest waned after removing it and
setting up the repository, I'm not currently a user although that could
certainly change.

Ken




SkipLists-klc.2.mcz (12K) Download Attachment
signature.asc (197 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: Issues with #collect: (Was: Re: Splitting Set and Dictionary)

Levente Uzonyi-2
In reply to this post by Andreas.Raab
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)?

Levente

>
> Cheers,
>  - Andreas
>

Reply | Threaded
Open this post in threaded view
|

Re: Re: Issues with #collect: (Was: Re: Splitting Set and Dictionary)

Igor Stasenko
2009/11/23 Levente Uzonyi <[hidden email]>:

> 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)?
>

Since i raised this question, my answer: keep it as it is.
It was just a notice, that current implementation having a little lack
of consistency.
But i can't find out a good examples where someone may require such
consistency for this method. So, if its not hurts a lot.. it can stay,
unless someone (interested enough) provide argumentation why it is
important, so we can discuss and proceed with change.

> Levente
>
>>
>> Cheers,
>>  - Andreas
>>
>
>



--
Best regards,
Igor Stasenko AKA sig.