[squeak-dev] The Trunk: Collections-ar.275.mcz

Levente Uzonyi leves at elte.hu
Fri Jan 8 15:26:15 UTC 2010


On Fri, 8 Jan 2010, David T. Lewis wrote:

> On Fri, Jan 08, 2010 at 08:04:01AM +0000, commits at source.squeak.org wrote:
>> Andreas Raab uploaded a new version of Collections to project The Trunk:
>> http://source.squeak.org/trunk/Collections-ar.275.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Collections-ar.275
>> Author: ar
>> Time: 8 January 2010, 9:03:46 am
>> UUID: 4eec6753-6711-094f-8a81-01f191056c76
>> Ancestors: Collections-nice.274
>>
>> Preserve findElementOrNil: for compatibility with external packages (i.e., extension methods in Dictionary etc).
>>
>> =============== Diff against Collections-nice.274 ===============
>>
>> Item was added:
>> + ----- Method: HashedCollection>>findElementOrNil: (in category 'compatibility') -----
>> + findElementOrNil: anObject
>> + 	"This method has been superseeded by #scanFor:
>> + 	It is here for compatibility with external packages only."
>> + 	^self scanFor: anObject!
>>
>
> I'm curious which external package is affected by this? I found
> the same issue in working with SystemTracer, and had been wondering
> if it might be a good idea to put #findElementOrNil: back in the
> image for compatibility (so thanks).

I'm curious too. I know that DynamicBindings used it and saw 
SystemTracer too. I fixed DynamicBindings and uploaded the code to
squeaksource.com/KomHttpServer. I also checked the SystemTracer code and 
found that the use of IdentityDictionary and MethodDictionary are the 
alternatives of NoAssocIdentityDictionary (if you remove 
NoAssocIdentityictionary, IdentityDictionary will be used). 
MethodDictionary may seem to be odd, but the code of 
NoAssocIdentityDictionary was probably the same as MethodDictionary's code 
in the past.

I guess we need a good deprecation policy. Maybe we should enable 
deprecation warnings by default and keep all deprecated methods until the 
next release.

>
> Similarly, SystemTracer also called #fullCheck. Should this be
> put back in the image as a no-op for compatibility, or is it
> just a SystemTracer oddity?

I'll look deeper into the extension methods and the Dictionary 
subclasses in the SystemTracing package and clean it up, but that may mean 
a trunk specific version until other forks pick up the trunk changes (if 
they ever do that). Until then, adding it back or just adding it as an 
extension method may be a good idea.

>
> (btw, my project for this weekend is to get SystemTracer working
> on little endian boxes so I can actually use it on my PC.)
>

Sounds great.


Levente

> Dave
>
>
>



More information about the Squeak-dev mailing list