Old call for volunteers still up to date

Marcel Weiher marcel at metaobject.com
Mon Apr 17 17:32:57 UTC 2000


Hi David,

I am not sure if I am capable of this.  I *am* sure that I've failed  
at least once at trying to explain things.  Here's another shot:

EncodingFilters can be found in the current image and are used by  
the Morphic Postscript-Canvas.  EncodingFilters formalize a specific  
kind of double-dispatch pattern that has various objects or an object  
graph such as a morphic world interacting with a single "encoder"  
object such as a morphic canvas.

The specific action to perform in such a pattern depends on both the  
specific morph in question and the specific canvas it is being drawn  
on.  A similar pattern holds for most encoding tasks, be it  
printing, storing, marshalling, etc.  Currently, these operations  
either (a) don't implement a double-dispatch (printOn:), which means  
that related operations cannot share code, or (b) implement their own  
ad-hoc double-dispatch mechanism.

Morphic's drawOn: method was modified last year from an (a)-style  
implementation, with a morph's drawOn: method sending drawOn: to its  
submorphs, to a (b)-style implementation that indirects through the  
canvas, giving it a chance to intervene.

So EncodingFilters aren't really some brand-spanking new concept,  
but just a factoring of a common pattern (the double-dispatch style  
from above) into a class, with subclasses for common variations and  
as starting points for specific subclasses.  At least that's the  
"Encoding" part of it.

The "Filter" part comes from having a simple + symmetric interface  
that allows encoding-filters to be arranged in processing pipelines,  
because each filter sends its results to a "target" filter.  To  
encode an object via a filter, you send it the #write: message with  
the object to be encoded as its argument.  The filter processes the  
object in a filter-specific way and sends the result to its target  
filter, again using the #write: message.

In techno-babble, one could call it a reactive data-flow  
architecture, because unlike "traditional" data-flow systems, a  
filter never actively pulls data, it just sits and reacts to data  
sent to it.

The reason I think EncodingFilters would be useful in refactoring  
printing is that they actually allow variants of printing operations  
to be easily defined as new filters.  Variants of #printOn: cannot  
easily reuse existing implementations because the #printOn: selector  
is hard-coded into the methods (an a-style implementation), whereas  
the double-dispatch of EncodingFilters allows the selector to  
effectively reside in the stream and thus be variable where  
appropriate.

I hope this is at least a little clear.

Marcel

> From: "Pennell, David" <dpennell at quallaby.com>
>
> Can you provide an explanation of EncodingFilters and why they are  
useful?





More information about the Squeak-dev mailing list