Hey guys, 
We need to be more organized about this - part of the changes you
enumerate are included in the ones I posted on the 23rd.

The other things I did -
* Give treatment 4 you describe to referencedClasses in the same class.
Compile -
MethodDefinition>>testLiterals
	self assert: (defn literals anySatisfy: [:e | e isVariableBinding and:
[(e key = #Halt) & (e value = Halt)]])
BTW, you can just cut out the extra arguments on calls to ChooserMorph -
 they never did anything. They're out of whack with the RB, because I
removed them there...

ducasse stephane <ducasse at iam.unibe.ch> wrote:
> Could you poste your version on the squeak Foundation wiki ;)
> I was planning to do that but I'm ___really___ overloaded. I just the
> emails.
> 
> on 29/9/01 8:45 pm, Hans-Martin Mosner at hm.mosner at cityweb.de wrote:
> 
> > Ok, so I've used Stef's Ginsu port, and with very little patching it ran
> > very nicely in 3.1.
> > Here's what I did:
> > 1. implement a method AlignmentMorph>>inset: (just returns self)
> > 2. changed UpdatingMenuItemMorph>>enablement: to ask the target and not
> > the wordingProvider
> > 3. implemented ChooserMorph>>choose... with additional args
> > (buttons+values+lines), which are silently ignored
> > 4. changed MethodDefinition>>classReferences and ...>>globalReferences
> > to use isVariableBinding instead of isKindOf: Association. BTW, does
> > anybody know why the various Associationlike subclasses of LookupKey are
> > not subclasses of Association?
> > 
> > Now I'm fooling around with the mechanism which moves definitions into
> > and out of the Unmanaged package. It seems to do the wrong thing for
> > clusters, because classes defined within different packages within the
> > same cluster can't see each other. Seems like at least one of
> > visibleClasses, allVisibleClasses, visibleClassNames and
> > allVisibleClassNames is broken :-( Without really understanding the
> > intended function of these messages, it looks to me that the overloaded
> > definitions of visibleClasses in Cluster and Package shadows the one
> > which seems most sensible to me, in Module...
> > 
> > Cheers,
> > Hans-Martin
> > 
> >