Blueprint-and OODL Framework

Howard Oakley

MCL's need…

Although Macintosh Common Lisp (MCL) 2.0 provides a lot of classes which make the development of applications straightforward, many of those using it feel the need for a more complete application framework, perhaps with the functionality of MacApp. So, at the time that the OODL SIG was starting to get going, some of us gathered electronically and are conspiring to build such an application framework, named "Blueprint" by Jeff Alger (a co-conspirator).

MCL has good window/view, dialog and dialog item classes, the latter in particular having been extended to provide almost every form of control and widget known to man, and menus are also well catered for. However, an examination of the class heterarchy (see the diagram on the facing page) with MacApp eyes shows that there are many gaps, particularly in command handling, printing and documents. In truth some of the classes which look attractive are in fact very shallow-for instance, the Application class arrived during the late development stage of MCL 2.0, and really handles AppleEvents and nothing else.

Discussion in the info-mcl mail group and elsewhere has suggested that the lack of a thorough application framework may be one of the major factors limiting the number of products developed with MCL, and we are all agreed that we would rather see the MCL development team spending their time making version 2.1 even better, rather than trying to design and build Blueprint too. So, it was a natural community project for those in the new OODL SIG to work on.

... IS dylan's gain

The other target platform at which we are aiming is Dylan, of course. We believe that having a solid but efficient and compact application framework coded in Common Lisp will be a good foundation for when copies of Dylan start to arrive amidst APDA's soluble packing chips. In case you have still not read a copy of Apple's initial language definition for Dylan, at least in its first incarnation its syntax is strongly Lisp (although there are hints that additional 'more popular' syntaxes will also be supported in the future).

A future with Dylan has some serious consequences on Blueprint's design. There is already a massive and highly sophisticated application framework for Common Lisp systems, the Common Lisp Interface Manager (CLIM). This is currently offered for other platforms at version 2.0, but is still in its previous version for MCL. None of us conspiring to Blueprint would wish to be seen to attempt to subvert or compete with CLIM, which is – and should remain – the standard cross-platform framework for Common Lisp. However, it is by no means small, and it does not quite enable the development of applications fully compliant with the Apple Human Interface Guidelines. Blueprint will be much smaller and must be oriented at providing those developing true stand-alone Macintosh applications in MCL or Dylan with full compliance with the guidelines.

Another significant application framework used in the Common Lisp world is Garnet, which has recently been made available in the public domain. However, even though Garnet is rather leaner than CLIM, it is still large and does not use the Common Lisp Object System (CLOS), the current (and now draft ANSI) OOP system for Common Lisp. This would clearly not be tenable when we are promoting MCL as an OODL!

PROGRESS

This summer has seen active discussion of a number of major design issues. We are agreed that from the outset, Blueprint will support fully factored applications. However, there was a malicious rumor circulating to the effect that trying to achieve this in MCL 2.0 would prove a problem; following some preliminary work, I can now confirm that not only is it possible, but it seems considerably easier than in MacApp or any of the 'mainstream' compiled languages.

Others within our informal group have been looking at architectural issues, and I am delighted that Jeff Alger has his Solution Based Modeling hat on, and is making sure that whatever we do will work well with the Goldstein and Alger approach to development, as well as having a sound basis. With a surprisingly large number of renegades from a MacApp past, I am confident that we will end up with a framework which is practical as well as theoretically proper-and lean, mean and purposeful.

Another area of general agreement is that Blueprint will be available in source code, and essentially free and without runtime licensing cost through OODL SIG. Our group has the benefit of many great minds, and our aspirations are high. If you feel that you can make a contribution-particularly if you can write good Common Lisp, as it is in 'implementors' that we are weakest-please mail me. n

NOTE: 'Blueprint' is but a working name, and no claim is made for it as a trade mark.