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
|