on October 27th, 2006 at 01:41 pm
For MOP nirvana and enlightenment, see: Open Implementations and Metaobject Protocols by Gregor Kiczales and Andreas Paepcke http://www.parc.com/csl/groups/sda/publications/papers/Kiczales-TUT95/for-web.pdf If I had to pick a subtitle, I would say "MOPs demystified". Print the document and read it on your favorite chair in a quiet room.
From the "Introduction" section of the referenced PDF:
The work presented in this book is based on the observation that much of the complexity in current application programs comes from the application programmer having to 'code around' deficiencies in the underlying operating system, programming language, object system or other substrate software. This happens when the application programmer would like a specific feature or behavior that the substrate does not provide.
But this book does not propose that substrate software should just "have more features to please more programmers." Instead, it suggests that substrates should be open in a way that allows programmers access to and control over the substrate's implementation in a way that allows the programmer to tailor the substrate to the needs of a particular application. This is called open implementation.
> I saw your explanation to other noobs. Made no sense to me. Instead of > searching for a pithy way of synopsizing what is going, it actually > would be easier simply to learn what is going on. In full. The shortcut > thinking of your synopsis is too lossy, and macro-writing requires > precise understanding of what is going on. You remind me of my early experiences learning French. It was often the case that students who thought they were speaking French could easily understand eachother while the francophones around them found them difficult to understand. This was caused by the students having access to English grammar and phonetics when interpreting the "French" utterances. For example, beginners have no trouble with, "le brun chaisses" even though the gender of the article is wrong, the adjective is in the wrong place, and so on. All that to say, I'm sorry that it seems I still have not entirely figured out defmacro's treatment of arguments. I thought I had, and I thought I was putting it in terms other newbies could understand. Thanks for pointing out that I'm still missing something.
CLIM has a "command loop" that is at a higher level than an event loop and that: * acquires a command. You might satisfy this demand by clicking on a menu item, by typing the name of a command, by hitting some kind of keystroke, by pressing a button, or by pressing some visible object with a command associated with it ; * acquires the arguments required by that command. These arguments are often associated with a "presentation type", and visible objects of the right presentation type can be clicked on to satisfy this demand. You can also type a textual representation of the argument, using completion, or you can use a context menu ; * calls the command on its arguments, usually resulting in some significant modification of the "model", i.e. the data structure representing your application logic ; * calls a redisplay routine (which might use incremental redisplay) to update your views of the model. Writing a CLIM application therefore consists of: * writing CLIM commands that modify the model independently of how those commands are invoked, and which may take application objects as arguments ; * writing display routines that turns the model (and possibly some "view" object) into a collection of visible representations (having presentation types) of application objects ; * writing completion routines that allows you to type in application objects (of a certain presentation type) using completions ; * independently deciding how commands are to be invoked (menus, buttons, presentations, textual commands, etc). By using CLIM as a mediator of command invocation and argument acquisition, you can obtain some very modular code indeed.
Keep digging for the ponies!