[squeak-dev] Don't rely on weak reference cleanup for lookup of undeclared references

Max Leske maxleske at gmail.com
Mon May 28 11:40:24 UTC 2018


Hi Levente,


On 28 May 2018 at 13:06:46, squeak-dev-request at lists.squeakfoundation.org (
squeak-dev-request at lists.squeakfoundation.org) wrote:

> Hi,
> Once again, there's a situation in the Fuel test suite that uncovered an
issue. Consider the following script:
>
> Object subclass: #Foo
> instanceVariableNames: ''
> classVariableNames: ''
> poolDictionaries: ''
> category: 'Kernel-Classes'.
> 10 timesRepeat: [(Smalltalk at: #Foo) rename: #Bar.
> (Smalltalk at: #Bar) rename: #Foo ]
>
> In 5.2-alpha this will open a warning dialog, as at some point one of the
class names will be undeclared. Class>>rename: only checks for an entry in
the undeclared dictionary without considering that the weak
> references may not yet have been cleaned up.
>
> I understand that this is not really a realistic real world use-case but
it's still annoying for tests. My current workaround is a forced GC after
*every* test in the entire suite (I use
> ClassFactoryForTestCase, so class names may be reused many times over).
Luckily, the impact on runtime isn't too bad.

Did you consider extending ClassFactoryForTestCase with an optional infix
name part for the generated names?
For example:

initialize

super initialize.
infix := ''.
self createdClasses: IdentitySet new

infix: aString

infix := aString

newName

^'ClassForTestToBeDeleted{1}{2}' format: {
infix.
self createdClasses size + 1 }

The you could specify a random infix, like UUID new asString36 to avoid
collisions.

Levente

Yes, I did consider that. However, in my opinion it should not be the users
concern. Using ClassFactoryForTestCase should in itself be sufficient to
guarantee the independence of tests. I knew what I was looking for, but for
someone with less experience this would just be a very annoying Heisenbug.

Cheers,

Max



>
> I'd appreciate it if this could be fixed. I'd be even more happy if I
could be notified of the fix, so that I can remove the workaround again.
>
>
> Cheers,
> Max
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180528/5fb4b8d9/attachment.html>


More information about the Squeak-dev mailing list