The Trunk: Collections-ar.275.mcz

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!

On Fri, Jan 08, 2010 at 08:04:01AM +0000, [hidden email] wrote:
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).

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?

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

Dave
 

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

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

Isn't this method were in 'private' category?
If so, then removing it and punishing those who using it would be a good move :)

--
Best regards,
Igor Stasenko AKA sig.

On Fri, 8 Jan 2010, Igor Stasenko wrote:

> Isn't this method were in 'private' category?

These were in the private category, but private in squeak is not the same
as in C++/Java/etc. Subclasses use private methods too.

> If so, then removing it and punishing those who using it would be a good move :)

This was the case and it turned out to be a "not that good" move. I think
deprecation is the way.


Levente

>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

On Fri, Jan 08, 2010 at 05:59:08PM +0200, Igor Stasenko wrote:
> Isn't this method were in 'private' category?
> If so, then removing it and punishing those who using it would be a good move :)

In this case the user is a subclass, so using the private method was appropriate
at the time the code was written.

Dave