Thanks, Colin!

On 1 January 2014 19:15, Colin Putney <colin at wiresong.com> wrote:
> Hi folks,
>
> I've just uploaded to the Inbox a series of packages that implement a new
> way of handling export and import of bindings between packages. The protocol
> for working with environments remains the same, but internally, it's quite
> different.
>
> The idea here is to make imports eager, rather than lazy. Instead of the
> "references" dictionary, which was a cache of the bindings that had been
> imported during method compilation, an environment now has a "bindings"
> dictionary, containing all bindings that are available during compilation.
> This is much easier to understand, and more similar to the old
> SystemDictionary approach, which should result in better compatibility.
> Environments now inform each other when bindings are added and removed, so
> that the bindings dictionary will always be up to date.
>
> Also, following Nicolas Cellier's idea, the system of imports and exports
> used to configure an environment is simpler and more "declarative" (to the
> extent that Smalltalk could ever be considered declarative!). This should
> make tool support easier to implement.
>
> To try it out, load the packages into a trunk image in this order:
>
> Environments-cwp.41
> Environments-cwp.42
> ShoutCore-cwp.40

Don't forget this one :)

> Environments-cwp.43
> Tests-cwp.281
>
> In my image, this passes all the Environments tests, and appears to clean up
> the bindings in the image nicely. This DoIt:
>
> classes := Bag new.
> CompiledMethod allInstancesDo:
> [:method |
> method allLiterals do:
> [:literal |
> classes add: literal class]].
> classes sortedCounts.
>
> answers this:
>
> 234856->ByteSymbol
> 58608->ClassBinding
> 17788->ByteString
> 12419->SmallInteger
> 10495->Association
> 3422->Array
> 2350->Float
> 2328->Global
> 1853->Character
> 863->AdditionalMethodState
> 207->LargePositiveInteger
> 61->LargeNegativeInteger
> 50->ByteArray
> 26->ScaledDecimal
> 4->WideString
> 2->Fraction
>
> We have lots of ClassBindings, and some Globals, but no Aliases. AFAICT, the
> associations in there are class variables. We should probably convert those
> to Globals at some point.

Why would we convert class variables to Globals? Do you mean we'd
represent the bindings of class variables as Globals (because the code
referencing the class variable has no way of knowing whether it's
referencing a class variable or a Really True global? If so, OK. I
guess "Global" might need a different name then. It's really
SomethingThatsNotAClassOrTraitButAvailableToMe.

frank

> Colin