On 15 May 2013 10:05, Frank Shearar <[hidden email]> wrote:
> On 14 May 2013 16:03, Bert Freudenberg <[hidden email]> wrote: >> >> On 2013-05-14, at 12:13, Frank Shearar <[hidden email]> wrote: >> >>> On 13 May 2013 22:09, <[hidden email]> 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. >> >> This is the Morphic trash can. Get it from the Object Catalog's "useful" category. Enable the preserveTrash preference, and the slideDismissalsToTrash pref too, for visual feedback. >> >> Now morphs that you delete via the pink halo handle get moved to the trash. Double-click the trash can to open the scraps book. > > Thanks! > > Apologies for the pun in the title; entirely intentional. The attached > changeset shows how we can pull the ScrapsBook class var out of > Utilities. It would require a second stage to remove the Utilities > class >> #initialize. > > (I'm using a ChangeSet because I've already got two System-affecting > submissions in the Inbox; I don't want to confuse myself any further.) > > One thing I haven't done yet is handling the double-clicking of the > trash can. Currently there are a bunch of MNUs because the ScrapBook > _uses_ a Morph, but isn't itself a Morph. Perhaps I should make it a > Morph, even though I generally prefer has-a over is-a. If I continue > with has-a Morph I can proxy methods directly. (I'm not a fan of > #doesNotUnderstand: proxying; it hides the proxied protocol.) > > Thoughts? the entire Utilities class. > frank > >> - Bert - >> >> >> move-trash-to-morphicextras.2.cs (6K) Download Attachment |
Free forum by Nabble | Edit this page |