[PEAK] Laziness, terminology, and the Trellis API

[Grant Baillie]

On 13 Mar, 2008, at 17:16, Phillip J. Eby wrote:

> ...
>
> Anyway, that's my rough sketch so far of how I think I would extend  
> and refactor today's API.  The key terms to learn are:
>
> Basic nouns/verbs: variable, @compute, @maintain, @perform
> Value/state control: initially=, resets_to=, .readonly, optionally.
> External connnection: @.connect, @.disconnect, @.transmit
> Miscellaneous: @task, @todo, attributes(**kw)
>
> That's only 14 words, but they can be combined in roughly 150 ways,  
> and I think the implementation will actually be a lot simpler than  
> the current crazy API that tries to guess what you mean by what  
> combination of explicit and inherited things you throw together.  In  
> addition, with this API it should be possible to make it so you can  
> refer to superclass versions of an attribute definition, for  
> explicit re-use.

Hi, Phillip

Overall, I really like the proposed, more direct, terminology, though  
at some point I will have to come up with concrete examples for some  
fraction of the cases to keep things straight in my head. I have a  
couple of comments/questions:

- I'm a little fuzzy on what the difference between maintain and  
variable is. Is it just that, in the simple case, "maintain" is the  
old trellis.rule, and "variable" trellis.value?

- On the use of 'resets_to', maybe there is some word related  
'baseline' or 'base' that works better? (Maybe I spent too much time  
looking at oscilloscope screens in my youth :).

- I also did a bit of a double-take at:

> @trellis.compute
> def someattr(self):
>    # get data from external source
>
> @someattr.connect
> def someattr(self, cell):
>    # arrange for cell.receive(value) to be
>    # called if external source changes
>    # return a key for unsubscriber to use to cancel

before I realized that this is actually legal (i.e. the reuse of  
someattr is fine), and is also the most direct again.

--Grant