Class cleanUp protocol

Hi -

Apologies for the many commit messages but I've adopted Keith's proposed
cleanUp protocol for classes. After writing a few more custom cleanups I
was just to fed up with all of the magic lore in this area. Instead, we
now have a common cleanUp protocol:

        MyClass class>>cleanUp: aggressive

This (class-side) method is called with an argument that indicates
whether to do aggressive, i.e., potentially destructive cleanup. Doing
aggressive cleanup will delete projects, change sets, uni-classes and
more. Gentle cleanup is expected to only flush transient caches. If your
class only has gentle cleanup you can simply implement

        MyClass class>>cleanUp

By default #cleanUp: delegates to this method (similar to
startUp/startUp: and shutDown/shutDown:). You can run cleanup by executing:

        Smalltalk cleanUp. "gently"
        Smalltalk cleanUp: true. "aggressive"

There is probably still more cleanups but I've taken a first round on
adding those cleanups that I was aware about. Hopefully, we can now put
all the various magic cleanup methods in ReleaseBuilder and Smalltalk to
rest.

Cheers,
   - Andreas

I'm happy to see that!
A common protocol is a way to go!

On 27 February 2010 01:41, Andreas Raab <[hidden email]> wrote:


--
Best regards,
Igor Stasenko AKA sig.

There are a bunch mentioned here:

<http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-July/137456.html>

Ken G. Brown

At 12:41 AM +0100 2/27/10, Andreas Raab apparently wrote:

I cant say I favour some of these design decisions

Smalltalk is a dictionary of classes. We were just talking about  
Smalltalk being overloaded.
SmalltalkImage represents the image, so if we are cleaning up the  
Image, it should go on there, shouldnt it?

Someone will need cleanUpAllExcept: <list of classes>.

I still think that the distinction between gentle and agressive, is  
better described with different selectors. We were originally  
implementing the freeSpace protocol, so we used #freeSomeSpace, for  
the gentle version. I can see that your version requires a less  
testing of whether or not a class implements a selector.

K.

On 2/26/10 9:41 PM, "Andreas Raab" <[hidden email]> wrote:
+1
Edgar

keith wrote:
> Someone will need cleanUpAllExcept: <list of classes>.

Here's a thought: if Announcements were in, asking for a cleanUp would
be an announcement. The cleanUp request would have been reified as a
real object, complete with as much description of the reasons for the
request as people see fit to provide.

Furthermore, the temporary-subscription-disablement could be used to
provide cleanUpAllExcept:.

Regards,
  Tony

I don't think so. Generally speaking, Announcements are events, not
actions. Cleanups are actions, not events. If we need a list of
exclusions then we can trivially add this to the current code without
dragging Announcements into it.

Cheers,
   - Andreas

On 2/28/2010 2:01 AM, Tony Garnock-Jones wrote:

Andreas Raab wrote:
> I don't think so. Generally speaking, Announcements are events, not
> actions. Cleanups are actions, not events.

I take your point that the intent of cleanUp does not fit well the
metaphor of an Announcement.

I think there is a deeper idea here, though: cleanUp is an instance of a
pattern where we are simulating the effect of a single message send
being multicast in (quasi-)parallel to *several* receivers who neither
know nor care about each others' existence.

Using your terminology, the body of each implemented cleanUp method is
the action, and the send of the message to the implementing class is the
proximal event. There's a more distal event, too: the call to Smalltalk
cleanUp. Between the distal and the proximal events is where the
simulation of multicast happens.

I had been thinking to reuse Announcements for that simulation of
multicast, because it's a pattern that recurs frequently, but you're
right that the intent is different: it's as if Announcements is merely a
*use* of this multicast pattern for, well, announcing :-)

Is there something deeper here, that Announcements can be built in terms
of? This seems like an important linguistic question. Where are the
languages, OO or otherwise, that support multicast as well as they
support unicast?

Regards,
  Tony