[plt-scheme] snips, snip-classes, and snippy questions.

At Thu, 15 Jun 2006 08:52:08 -0700, Jordan Johnson wrote:
> I understand from the MrEd docs that, by overring read, a subclass of  
> snip-class% tells how to handle the decoding of a snip that's stored  
> in encoded form.  Where and how does the ENcoding happen?

When an editor<%>'s content is written to a stream, it calls the
`write' methods of its snips. When an editor's content is read from a
stream, it calls the `read' methods of classes named in the head of the
stream.

> For want of examples of the above, I've looked around in the sources  
> in collects/ but found two different ways of handling the reading:   
> Some snipclasses make a snip with default fields and then call (send  
> editor read-from-file stream-in #f), and others do some variation on  
> getting and reading a byte stream from the editor stream.  Where is  
> the input data format specified (I guess that's the same question as  
> above), and is there documentation I'm seriously missing?

There are two levels of format specification:

 * The snip class's format, which is expressed in terms of the
   editor-stream methods.

 * The format chosen by a particular editor-stream implementation for
   its backing store (e.g., bytes for a stream that goes to/from a
   file).

The former is up to individual snip classes (or, where the snip class
defers to an editor, the editor class). The latter is not currently
documented independent of the code (though it really should be, of
course).

> Finally, a question about the philosophy of snips:  I'm working with  
> compound data structures (basically a graph of structs with string,  
> sym, and int fields) whose parts will be viewed in several different  
> ways through several different interfaces.  For example, in my  
> pasteboard I want the snips to display only a terse label, but  
> provide access to the underlying data via callbacks.  Making all the  
> fields a part of my snip subclass is what got me into the trouble  
> suggested by my questions above; making the snips merely a facade  
> that points to the "real" data structure seems to preclude use of the  
> built-in encoding facilities by the chicken/egg problem it raises in  
> the read method.

I'm not sure I understand, but it sounds like a snip is merely a view
on some model, and one model can have multiple views. In that case, it
seems like the model needs to be saved somehow in the header of the
editor's encoded form, and then the encoded form of a snip needs to
refer to that model part for which it's a view.

If there's a 1-to-1 mapping between views and models, then I don't
quite understand why the snip can't just extract what it needs from the
model for writing, and then reconstruct the model when reading. In
other words, it doesn't seem to matter whether the model data is in
immediate fields or indirected through another data structure.

Matthew