re: aspect-oriented programming

It's been a few years since I looked at this, I'll have to refresh
my memory on it.  There my be some good similarities in it.

The motivation came from the things I saw when I had run my
analysis tools on various classes... a recognition that certain
"patterns" appeared over and over again.

Perhaps an important point:

	1) In Smalltalk, we can only interact with objects
	   by sending them messages.

	2) We do not know that a message will be understood,
	   but we do expect it to be understood.
	   
	3) The result of a message send, if it is understood,
	   is always an object.

(3) is actually rather important.  It allows one to create objects
as results of message sends, and then send messages to those objects...

	newThing := ( someObject hasPropertyX )
		ifTrue: [ someObject propertyX ]
		ifFalse: [ someObject differentResult ].

How many objects are there?  At first glance, maybe one... someObject.
But this is wrong... there are a lot of objects here, much more than
what I was used to thinking about...

	< someObject >
	< someObject hasPropertyX >
	< someObject propertyX >
	< someObject differentResult >
	< ( someObject hasPropertyX )
		ifTrue: [ someObject propertyX ]
		ifFalse: [ someObject differentResult ] >

We could also include < newThing >, even though it is a variable
that does not itself result from a message send ( assignment is
a bit different ).

Each of these things is an object.  And out of this list, we
see that we send messages only to some, while the rest are
more or less passive ( we build them, but do not interact
with them other than to toss them around ).

	< someObject >
		hasPropertyX
		propertyX
		differentResult
		
	< ( someObject hasPropertyX ) >
		ifTrue:ifFalse:

These sets of messages represent portions of an expectation signature...
these are messages we think we can send to these objects.

So that is the sort of thing I was doing when I was thinking about
these patterns...  the one above is similar to a very common one,
but we see that due to condition (3) there are actually many variations
of this one... since the pattern is object based, not variable based,
and objects could be obtained in many ways.

This sort of analysis generates a huge amount of information, much
greater than the original source code.  So... when I was thinking
of patterns, I was motivated by the recognition that there were
things occurring over and over, and it would be great if there
were some way of automatically recognizing them and saying something
like 'type x lazy instantiation of y' rather than the horde of information
I was seeing. And then, if it were possible to recognize these things,
then it would also be possible to use them in synthesis as well as analysis,
so that they would become first-class building blocks, parameterized
or whatever to match the particular case in question.

That's basically it... but a great deal of work remains to be done
to make it useful.

les