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 @
- http://bugs.impara.de/
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:[EMAIL PROTECTED]
_______________________________________________
Beginners mailing list
Beginners@lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/beginners
