[squeak-dev] Unloading Traits

Frank Shearar frank.shearar at gmail.com
Thu Aug 8 07:38:19 UTC 2013

On 7 August 2013 22:51, Tobias Pape <Das.Linux at gmx.de> wrote:
> Am 07.08.2013 um 23:04 schrieb Frank Shearar <frank.shearar at gmail.com>:
>> In my exploration of the interface between Traits and Monticello, I
>> found that Trait class >> #unloadTraits depends on Monticello.
>> This is unfortunate, because Traits should be a much lower level
>> package than Monticello.
> Au contraire. It’s a languae feature, yes, but so is AspectS or OMeta..
> Traits are nice and such but just because it provides language instead of library, it
> shouldn’t be more privileged.

Well, I don't know what privilege means here. What I do know is that
Traits depends on a very small number of packages, and provides a low
level feature / language extension. Monticello does neither. (This is
fine and good and proper. I'm not saying either is more important.)
These methods are very definitely Monticello methods; they make no
sense to the Traits package in the absense of Monticello.

I ran a little experiment last night, and pulled these methods out
into a MonticelloForTraits package. We end up with this kind of

digraph {
  MonticelloForTraits -> Traits
  MonticelloForTraits -> Monticello

In other words, this makes Traits cleanly unloadable (just that an
unload script must unload possibly (*) two packages), and keeps Traits
clean. The only cost is an extra small, highly specific package.


(*) Remember, Monticello ought to be unloadable too!

>> After all, Traits implements something that
>> in other languages would be a language feature, while Monticello is
>> "merely" a source control tool.
>> I appreciate the desire to make Traits responsible for unloading
>> itself, and for Traits to be unloadable at all. Is there another way -
>> without Smalltalk >> #at: - to remove the dependency?
>> (I can kind've see a case for Trait unloading to live in
>> ReleaseBuilder. Kind've. But let's not make System >>
>> #unloadAllKnownPackages any more of a problem than it already is.)
>> frank

More information about the Squeak-dev mailing list