The debugger shows that, after x := Collection new and then again x := OrderedCollection new, the Compiler tries to automagically find variable x and so scans the dictionary which contains the automagically declared variables, thereby #hash is sent to the already declared variable x (an association which still contains Collection new), and: bang!
A similiar situation can be provoked with printIt on
(Collection new)
and on
(Collection new) hash
Good find Brent. I suggest you create yourself an account @
and report your find. Automatic variable declaration should not choke the compiler.
/Klaus
P.S. Workspace has a menu which offers "reset variables" and enable/disable of automagic variable declaration.
On Sun, 21 Jan 2007 09:37:33 +0100, Herbert König wrote:
Hello Brent,
BM> Which produced an error on Collcetion>>add: as a BM> subclassResponsibility which seems correct. But when I change it BM> back toOrderedCollection I get an error that Collection>>do: BM> issubclass responsibility. However this is EXACTLY the same code BM> asbefore that worked. But now I have to exit the Workspace BM> andstart another before the code works again. Am I doing BM> somethingwrong?
I'm not experienced enough to really reply to this, but:
Something sticks to an old (Collection) incarnation of X. If you change your code like this:
| x | x := OrderedCollection new. x add: 'blue'. x do: [:a | Transcript show: a; cr]
making x local to the running code, the problem goes away.
First I thought the doIt would stick to x but
Smalltalk forgetDoIts
didn't help either.
So now I'm as curious as you to a reply of someone who really knows :-)
Cheers
Herbert mailto:herbertkoenig@gmx.net