Unloading Traits

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. 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

Am 07.08.2013 um 23:04 schrieb Frank Shearar <[hidden email]>:

> 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.

On 7 August 2013 22:51, Tobias Pape <[hidden email]> wrote:
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
structure:

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.

frank

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 08.08.2013 um 09:38 schrieb Frank Shearar <[hidden email]>:

On 7 August 2013 22:51, Tobias Pape <[hidden email]> wrote:


Am 07.08.2013 um 23:04 schrieb Frank Shearar <[hidden email]>:

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
structure:

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.


I would like that more :)

Best
        -Tobias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)

iEYEARECAAYFAlIDTScACgkQcPVIrP6PLKu62gCeMuHluEgGa2amjar1XmbGSbDD
GnsAn3ewqJVaaz4vUK/Ahduw3OhgBuzP
=nZC7
-----END PGP SIGNATURE-----