From commonloops-request@nsfnet-relay Thu Aug 29 23:20:43 1991 Received: from uk.ac.ed.emas-a by aiai.ed.ac.uk; Thu, 29 Aug 91 23:20:42 BST Via: UK.AC.NSFNET-RELAY ; (to uk.ac.edinburgh.emas-a) 29 Aug 91 23:19:44 bst Date: Thu, 29 Aug 91 18:07:44 GMT From: barmar@com.think (Barry Margolin) Subject: Review of "The Art of the Metaobject Protocol" Sender: commonloops-request@nsfnet-relay To: comp.lang.clos@edu.ohio-state.cis Message-Id: <1991Aug29.180744.18006@Think.COM> Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id <19872-40@sun2.nsfnet-relay.ac.uk>; Thu, 29 Aug 1991 19:40:40 +0100 Received: from NSFnet-Relay.AC.UK by vax.NSFnet-Relay.AC.UK via List-Channel id aa15042; 29 Aug 91 19:13 BST Received: from [128.146.8.50] by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa15029; 29 Aug 91 19:12 BST Received: by news.cis.ohio-state.edu (5.61-kk/5.910703) id AA06893; Thu, 29 Aug 91 14:10:30 -0400 Received: from USENET by news.cis.ohio-state.edu with netnews for commonloops-mail@cis.ohio-state.edu (comp.lang.clos@cis.ohio-state.edu); contact usenet@news.cis.ohio-state.edu if you have questions. Organization: Thinking Machines Corporation, Cambridge MA, USA Original-Sender: commonloops-request@edu.ohio-state.cis Status: RO A Review of The Art off the Metaobject Protocol by Gregor Kiczales Jim des Rivieres Daniel G. Bobrow MIT Press, 1991 ISBN 0-262-61074-4 335 pgs, paperback Review by Barry Margolin Most of the response I got to my review of "Understanding CLOS" was related to my parenthetic comment that I bought that book when I was looking for "The Art of the Metaobject Protocol". Several people pointed out that the book I wanted was already on the shelf at the MIT Press Bookstore, right around the corner from Quantum Books (had I realized that the book was being published by MIT Press, I might have thought to look there first). So I went and got it. This was one of the most enjoyable technical books I've read in a while (up there with Padlipsky's "The Elements of Networking Style"). I was expecting it to be a slow read, because of the advanced nature of the subject matter, but I breazed through it in about a week of reading it mostly while eating lunch (well, I took long lunches on those days -- it was hard to put down). Naturally, for anyone interested in doing CLOS metaprogramming, this book is a must. It describes the metaobject protocol (henceforth, "MOP") in full detail, and explains how the different pieces interact. There are numerous good examples, including some of the popular uses for the MOP (e.g. implementing a metaclass that counts its instances, and alternate slot storage strategies). But this book is much more than just a description of the MOP, and I would recommend it to any advanced object-oriented programmer or language designer. It begins with an introduction that justifies the need for metaobject protocols. The first half of the book then takes the reader step by step through the evolutionary design of a MOP (a slightly simplified version of the actual CLOS MOP). The second half describes the CLOS MOP, and finally in the appendices there is a complete implementation of the MOP subset (actually, it's something in between the subset that was designed in part I and the full CLOS MOP). Part I is the part that should be of most interest to OO programmers in general, as tour through the OO design process. In effect, the reader is watching over the shoulder of an expert OO designer in action. I don't know about most of you, but I learned most of what I know about good programming by sitting next to colleagues while they worked, or by making later modifications to their programs; there's no substitute to looking at good code, and having the programmer explain *why* it is written the way it is. This book does this. Of course, most OO programming texts have lots of examples and explanations. The problem is that they are usually toy applications or completely isolated examples. OO programming is often overkill for simple programs, so the examples aren't really motivated well. In contrast, metaobject programming is a complex area, and well-suited to OO techniques. As the protocol evolves, we understand why each piece is added. This tour through the design process also excellently illustrates the difficulty of OO design, and the advantages of using a flexible language like Lisp or Smalltalk for OO programming, versus more restrictive languages like C++. It's very difficult to predict many of the pieces of the protocol at the beginning of the project. Most of the classes in the final design were there at the beginning, but the interactions between the classes and methods have evolved drastically. The description of the MOP uses an analogy to a stage play. The basic language corresponds to the action seen on the stage, while the underlying implementation corresponds to the backstage activities. In this scheme, the MOP corresponds to allowing the audience to see and direct some of the backstage work; I was reminded of interactive theatre. Extending this analogy beyond that used by the authors, this book is like a diary by the playwrite made while he was writing the interactive play (adding interactivity to an existing, static play), explaining where he allows the audience members to become directors, and the extent to which they may modify the action or scenery. To make it fully relexive, the play is about the process of writing plays! Part II, which describes the CLOS MOP, is a good example of a way to document an OO library. It carefully describes the ways in which a programmer of subclasses may augment and/or override methods and still allow the system to function properly. This is one of the more difficult areas of OO language use; often, a programmer is forced to examine source in order to determine how to define a new class that should participate in an existing protocol. The description is good, but the extensive use of prose underscores a missing facet of most OO languages, including CLOS: formal protocol specifications. In fact, there are some ways in which I feel CLOS took a step backward from one of its ancestors, Flavors: for instance, Flavors allows the programmer of a flavor to declare it to be an "abstract" base flavor (i.e. it may only be used to define subflavors, but not instantiated on its own), and to declare methods and instance variables that must be provided by any subflavors in order for them to be instantiable; C++ also allows a class designer to indicate that it is a virtual base class, by defining virtual methods and initializing them to 0. Perhaps such features could be added to CLOS using the MOP, though (but it wouldn't help in this case, because the MOP classes can't use them). Maybe now that the CLOS designers have polished CLOS and reached a milestone in the MOP design, the next step should be a language for formally defining protocols. Finally, it has a beautiful cover. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar