This is perhaps an even better question now that BlockClosures are in the
air.

Take Celeste. Celeste filters are little bits of block *bodies* that get
wrapped in a calling block, then stored (in two forms) in a couple of
dictionaries in class variables.

So you get stuff like:

	...
	CustomFilters at: filterName put: newDefinition.
	CustomFiltersCompiled at: filterName put: (self class
					makeFilterFor: newDefinition).
	...

and:
	makeFilterFor: filterExpr
		"compile a given custom filter"
		^Compiler evaluate: '[ :m | ', filterExpr, ']'.

Am I the only one who thinks this horks a small goat?

It sure makes developing complex filters a pain. And it's hard to have
interesting sharing between filters, or auxilary filter methods (indeed,
it's hard to get at things in general since it's not evaluated *in* a
class context), or have versions, changed filters, etc. etc. etc. etc.

ComSwiki is like this in *spades* (which I fough with Je77 about quite a
bit :)).  Perhaps what is needed is a better way of managing
"standalone" functions? Code tidbits? Anonymous classes?

Is there anything wrong with using SomeClass
class>>addSelector:withMethod:? Ok, you have to compile the method
yourself. Hmm. And maybe put it in the right
place. ClassDescriptions...AIEE MY SKULL IS EXPLODING. Well, no, not
really, but it does seem a bit
nontrivial. Aha! ClassDescription>>compile:classified:

And a buncha other things whose use cases aren't entirely obvious to me :)

But #compile:classified: works dandy, leaving me with:

<CSOTD>String compile: 'helloBijan
		^self inform: ''hello bijan''' classified: 'silly methods
that surely will annoy stef'</CSOTD>

It occurs to me in all this that ClassDescription really is fun. I suspect
that "anonymous classes" or generally Throw Away classes can be well
structured with varients of this class.

Anyhoo.

Hmm. I guess it's not Of The Day if I post more than one in a single day
:)

Cheers,
Bijan Parsia.