On 13 May 2013 22:09,  <commits at source.squeak.org> wrote:
> Frank Shearar uploaded a new version of System to project The Trunk:
> http://source.squeak.org/trunk/System-fbs.529.mcz
>
> ==================== Summary ====================
>
> Name: System-fbs.529
> Author: fbs
> Time: 13 May 2013, 10:09:14.405 pm
> UUID: 2ba98257-9342-4eee-a927-a0c3d6deaf41
> Ancestors: System-fbs.528
>
> Another tiny step in breaking the System -> MorphicExtras dependency. Locale class>>migrateSystem moves to MorphicExtras because, while it refers to other packages as well, MorphicExtras form the largest minority of package references.
>
> =============== Diff against System-fbs.528 ===============
>
<snip>
> Item was removed:
> - ----- Method: Utilities class>>scrapsBook (in category 'scraps') -----

I realised this morning that this particular change is insufficient.
There are a cluster of methods - the entire 'scraps' category - that
ought to move to MorphicExtras [1]. That, too, is insufficient,
because these methods all use the ScrapsBook class var. I propose to
create a new class, ScrapsBook, in MorphicExtras, that implement
versions of these methods. "Versions" because ScrapsBook will be a
normal class holding an instvar named 'book'. ScrapsBook default will
return a lazily instantiated canonical ScrapsBook, and the existing
Utilities class methods in 'scraps' will simply delegate to this.

That at least centralises the access to the ScrapsBook. I don't know
how the ScrapsBook relates to the rest of the image, so I don't know
how to fix the broader issue. In other words, System will still depend
on MorphicExtras, but through an instance of a class, rather than
through a class var.

Thoughts? Particularly, how do I test that I haven't smashed anything
before even bothering to submit something to the Inbox?

frank

[1] Because it uses a BookMorph. This, sadly, makes Morphic depend
that little bit more on MorphicExtras. The solution to that would be
moving BookMorph and friends to Morph, which seems undesirable.