[squeak-dev] Collections

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

[squeak-dev] Collections

Levente Uzonyi-2
Hi!

I uploaded 5 packages which give cleaner and faster implementations of Set
and subclasses' #fixCollisionsFrom:. These changes also replace the
copying of these objects with the more common #copy and #postCopy methods.
The suggested load/merge order is:

Collections-ul.141
Kernel-ul.249
Collections-ul.142
Kernel-ul.250
Collections-ul.143

While I was doing these changes I came to the conclusion that
Set >> #findElementOrNil: should be removed. It checks for a case which
never happens (normally). I'm about to update #scanFor: to raise an error
instead of returning 0 and replace all sends of #findElementOrNil: with
#scanFor:. If you know something that's against this change, let me know.

Cheers,
Levente

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Collections

Igor Stasenko
2009/9/22 Levente Uzonyi <[hidden email]>:

> Hi!
>
> I uploaded 5 packages which give cleaner and faster implementations of Set
> and subclasses' #fixCollisionsFrom:. These changes also replace the copying
> of these objects with the more common #copy and #postCopy methods.
> The suggested load/merge order is:
>
> Collections-ul.141
> Kernel-ul.249
> Collections-ul.142
> Kernel-ul.250
> Collections-ul.143
>
> While I was doing these changes I came to the conclusion that Set >>
> #findElementOrNil: should be removed. It checks for a case which never
> happens (normally). I'm about to update #scanFor: to raise an error instead
> of returning 0 and replace all sends of #findElementOrNil: with #scanFor:.
> If you know something that's against this change, let me know.
>

Nothing what i know..
Just be careful, do not break the weak dictionaries :)

> Cheers,
> Levente
>
>



--
Best regards,
Igor Stasenko AKA sig.