generic views [Was: Tweak position?]

Brian Rice water at tunes.org
Thu Feb 10 00:16:12 UTC 2005


I second that, mentioning of course my "Chalk" UI project  
(vision/overview at http://slate.tunes.org/doc/ui/) for Slate  
(http://slate.tunes.org/), although I haven't even touched  
styling/transformations, just the rendering and basic  
how-to-mix-ideas-in-the-same-system questions on morphs and  
presentations.

And every interface is abstracted with a stream/resource protocol at  
the base level, keeping the core implementation itself generic.

On Feb 9, 2005, at 8:38 AM, Howard Stearns wrote:

> I'd like to suggest a way to architect the problem technically. I  
> realize it may duplicate what people are thinking, or be completely  
> incompatible, or just plain irrelevant. Apologies. I've been lurking,  
> but don't have the Squeak-specific background to know how far off the  
> mark the following is.
>
> In my experience, some attempts at multiple view presentations have  
> failed because they fail to realize that there is more than one axis  
> along which to make decisions about what is in common between  
> presentations for different media-or-toolkits vs what is different.  
> It's not just a matter of choosing inspector X or inspector Y, browser  
> X or browser Y, at top level.
>
> For example, media-or-toolkit X may want to share structure with Y for  
> the two realizations of an inspector. In the HTML-generating world,  
> for example, systems like uPortal separate the structure of the  
> presentation (defined using XSLT) from the style of the components of  
> that structure (defined using CSS).  An application is broken down  
> into various structures used for presentation (the XSLT part), and in  
> different contexts the same application data might use different XSLT  
> to specify that structure. Separately, the various bits of structure  
> that are produced by one XSL or another might be styled using the same  
> CSS. Or they might well use their own CSS. The point is that the  
> specification of structure and style are separated.
>
> Of course, XSL and CSS don't provide for a lot of reuse of separately  
> developed components. (If you're a language freak, you might be  
> interested in IBM's Darwin Information Typing Archicture (DITA), which  
> provides for multiple inheritance of XSLT by explicitly doing in XSL  
> attributes exactly what a dynamic language implementation of multiple  
> inheritance does under the surface. Neat stuff.)
>
> In the late '80's I worked on a multiple axis view inheritance system  
> that was used in a product for over 10 years and took the company  
> through an IPO and two buyouts. We had a geometric expert system and  
> needed to produce geometric and attribute interfaces to more than 10  
> CAD systems (and growing). Some were 2d, some 3d, and all had quite  
> different ways of getting information in and out. Our expert system  
> used a message-passing style of OO.
>
>    For output, we created a Writer object representing the  
> capabilities of the CAD system. Each Writer had primitives for basic  
> capabilities like line and arc. Some of these produced results right  
> away, and others kept state that was later dumped when the serial  
> connection was closed. Writers for a CAD system that worked like other  
> CAD systems could inherit from the corresponding Writers. (We had  
> multiple inheritance, but didn't use it much for Writers. However, 2D  
> CAD systems did tend to inherit along a branch that inherited the same  
> 3D-to-2D projection code.) Different styles were produced by providing  
> initialization arguments to a Writer, by side-effecting Writers during  
> use, or by subclassing the Writers altogether.
>
>    But we did not simply hand one of our geometrical expert-system  
> application objects to the Writer for output, nor did we define output  
> methods on the application object that invoked stuff on the Writer.  
> When asked for serial output, the Writer was asked to produce a  
> delegation object for the application object. Our applications had a  
> whole tree of application objects, and the machinery cached the  
> Writer-specific delegations so as to produce a shadow tree of  
> delegation objects. New serializations (e.g., a new file) cleared the  
> cache. Each shadow/delegation object pointed back to the application  
> object as needed. (Not unlike Tweak?) The Writer-specific  
> shadow/delegation objects often had complex structure of their own.  
> For example, a 3D Cube application object might present on  
> solid-modeling CAD systems as a single Cube solid, while wireframe CAD  
> systems might use 12 Line objects. The Writer for the solid modelers  
> produced a shadow object that just delegated everything back to the  
> Cube application object. However, the Writer for the wireframe CAD  
> systems produced shadow objects that had their own little tree of 12  
> Line objects. The Line objects were, in turn, output in the normal  
> way, just as if they were the original application objects. This  
> allows for a huge amount of reuse in how different CAD system produce  
> similar structures, even if the syntax of individual item  
> representation was quite different.
>
>   Even though we had hundreds of application objects in the system,  
> and customers created thousands more, we regularly created  
> presentations for new CAD systems in a week or so. Mostly it was a  
> matter of defining only the most primitive methods for the new Writer,  
> reusing a lot of the delegation objects.
>
> My thinking is that the internal structure of browsers and inspectors  
> and such are often appropriate to share between different graphics  
> systems, somewhat orthogonally to how the graphic systems themselves  
> work.
>
> Since that time, the Lisp community has developed a much more  
> straightforward way to do this, using multiple dispatch. Generic  
> functions are like Block objects. However, instead of dispatching  
> between methods based on the "receiver" (or what is effectively the  
> first argument), the dispatch is made based on all the arguments. In  
> the Common Lisp Interface Manager (CLIM), a presentation is created by  
> calling a generic function that dispatches on the application object,  
> the application-defined View for the current context, and the Media (a  
> stream) on which the presentation is to be displayed.  Views can  
> inherit from other Views, Media can inherit from other Media. Methods  
> for the presentation generic functions can be created for any specific  
> combination of application object, View, and Media, and these methods  
> can (and frequently do!) call the next more general applicable method.  
> (Presentations are actually objects that could be further broken down,  
> somewhat like the shadow objects in the CAD output. But in practice,  
> the multiple dispatch gives sufficient flexibility with reuse, that I  
> think applications rarely messed with the internals of Presentations.)  
>  The process is essentially doing more flexibly in one line what the  
> CAD output system did by dispatching to Writers and then to delegation  
> objects and then back to the Writer. The whole mechanism fosters even  
> more code reuse when the dispatch can use a form of multiple  
> inheritance within application object, View, and Media. (The tradeoff  
> is basically more branches within the objects, or more arguments for  
> dispatching within the generic function.)  Generic functions are  
> pretty easy to write in Smalltalk. (Mine at  
> http://groups-beta.google.com/group/comp.lang.smalltalk/browse_frm/ 
> thread/ad5d131840cccafd/b6e691d9834f8b90 just uses the class  
> precedence list implied by Smalltalk's normal single inheritance, but  
> it could easily be changed to use any more complex property.)
>
> -Howard
>
>
>
>
--
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/




More information about the Squeak-dev mailing list