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