Object-Oriented NoteCards SASI Final Report 4.0 Object-Oriented NoteCards A short programming experiment was conducted during the SASI project. The experiment involved rewriting a portion of the NoteCards system in the Loops object-oriented programming language developed at Xerox PARC. The objective was to test the feasibility of a complete translation of NoteCards to Loops and to learn the advantages and disadvantages of such a conversion. The result was a NoteCards subset which could open and close notefiles and retrieve and write individual cards. In addition, this mini-NoteCards was able to handle multiple open notefiles, a feature still not implemented in standard NoteCards. Though the Loops version is far from a complete system, we feel that the exercise was valuable. Experience was gained programming in Loops and lessons were learned that will be useful in future efforts to create an object-oriented implementation of NoteCards. This section contains a brief description of the Loops programming environment and the Loops version of NoteCards. Some of the pros and cons of a future conversion, perhaps to CommonLoops, the recent implementation of Loops in CommonLisp are also discussed. 4.1 Loops and CommonLoops Loops is an object-oriented programming environment developed at Xerox PARC on top of the Interlisp programming language. Loops is perhaps best known for merging four different programming paradigms in one environment: procedural, object-oriented, rule-based, and data-driven. For our purposes the first two paradigms are most important. Procedural programming uses standard function calls as in Interlisp. Object-oriented programming, on the other hand, divides the world into objects which are instances of classes. Classes are organized into a class inheritance hierarchy the elements of which are themselves instances of meta-classes. Each class associates functionality with its instances by means of methods. These are invoked by messages sent to the object. CommonLoops is a new version of Loops being implemented in CommonLisp. It is in fact being proposed as the objects standard for CommonLisp. As yet, CommonLoops does not include the powerful Loops environment, but nonetheless provides several improvements over Loops. These include multi-methods, joining the syntaxes of function calling and method invoking; meta-classes capturing different object-oriented programming styles; and speedups through the use of microcoded primitives. 4.2 The NoteCards in Loops Experiment In February of 1985, we implemented a small subset of NoteCards in Loops. This mini-NoteCards can open notefiles in the standard format and bring up cards. It can also close cards and notefiles. It also adds the ability to keep multiple notefiles open at once. Much of the code was taken directly from the Interlisp version adding only Loops "wrappers." Organization of NoteCards into an object hierarchy was quite natural, as that structuring style is already simulated via the Types Mechanism (see Section 1.1.2 and Appendix B). Finally, the multiple open notefiles capability was a natural outgrowth of the use of separate notefile object instances for each open notefile. On the other hand, no attempt was made to port several important parts of the system. These include the user interface to cards, most of the notefile operations, and the representation and manipulation of links. Rather than a simple port of these to Loops, we need to rewrite much of this code from scratch. Thus the hardest part of the conversion to Loops is not in the shift to object-oriented programming, but in the rewrite that was required anyway. 4.3 Pros and Cons of Object-Oriented Programming From our experience in this experiment, we now have some grasp of the tradeoffs to be considered in a shift from Interlisp to CommonLoops. The three main areas of interest are code maintainability, modularity, and efficiency. We do not consider the cost of conversion among these, because it has been decided that NoteCards will be rewritten anyway, if not in CommonLoops, than in Interlisp. Thus the decision is really what language the next major release of NoteCards will be written in. The areas of modularity and maintainability work together. That is, the modularity afforded by object-oriented programming helps to ease the burden of code maintainability. This is because the effects of changes are localized to particular objects. New changes can be tried out by specializing an object or "mixing in" new functionality and later easily retracted or absorbed. Loops provides a comprehensive browser-based debugging environment that has been used successfully to build and maintain several large systems. Though CommonLoops does not currently have such an environment, we expect it to be added in the near future. Efficiency considerations are less clear. Though running NoteCards on top of Loops incurs a significant space penalty, many of the CommonLoops primitives are being designed into forthcoming versions of Interlisp so that a CommonLoops implementation should be smaller. Similarly, some of the CommonLoops primitives are being microcoded to gain speed. However, it will always be the case that simple function calling is faster than message passing. In addition, it is generally recognized (though hard to prove) that large systems written in an object-oriented language are less efficient than those written in a procedural language. These penalties are due mostly to the extra message-passing overhead imposed by object-based modularity. It is also possible that object-oriented NoteCards will be more easily tailorable to different applications. But this will have to be verified in the coming year by the SASI-II tailorability project. To conclude, we feel that ease of code maintainability and readability more than offset possible efficiency drawbacks. Thus we plan to write the next release of NoteCards (Release 2.0) in CommonLoops. (LIST ((PAGE NIL NIL (0 0 612 792) ((FOLIO NIL (PARALOOKS (QUAD CENTERED) CHARLOOKS (FAMILY NIL OVERLINE OFF STRIKEOUT OFF UNDERLINE OFF SLOPE REGULAR WEIGHT MEDIUM)) (270 36 72 36) NIL) (HEADING NIL (HEADINGTYPE DOCUMENT) (72 756 468 36) NIL) (HEADING NIL (HEADINGTYPE CHAPTER) (72 756 468 36) NIL) (TEXT NIL NIL (72 72 468 648) NIL))) (PAGE NIL NIL (0 0 612 792) ((FOLIO NIL (PARALOOKS (QUAD CENTERED) CHARLOOKS (FAMILY NIL OVERLINE OFF STRIKEOUT OFF UNDERLINE OFF SLOPE REGULAR WEIGHT MEDIUM)) (270 36 72 36) NIL) (HEADING NIL (HEADINGTYPE DOCUMENT) (72 756 468 36) NIL) (HEADING NIL (HEADINGTYPE CHAPTER) (72 756 468 36) NIL) (TEXT NIL NIL (72 72 468 648) NIL))) (PAGE NIL NIL (0 0 612 792) ((FOLIO NIL (PARALOOKS (QUAD CENTERED) CHARLOOKS (FAMILY NIL OVERLINE OFF STRIKEOUT OFF UNDERLINE OFF SLOPE REGULAR WEIGHT MEDIUM)) (270 36 72 36) NIL) (HEADING NIL (HEADINGTYPE DOCUMENT) (72 756 468 36) NIL) (HEADING NIL (HEADINGTYPE CHAPTER) (72 756 468 36) NIL) (TEXT NIL NIL (72 72 468 648) NIL))))) PAGEHEADINGDOCUMENT PAGEHEADINGCHAPTER  TIMESROMAN  TIMESROMAN TIMESROMAN  TIMESROMAN  TIMESROMAN u Vn F&o*2{w>z