[PEAK] Laziness, terminology, and the Trellis API
grant at osafoundation.org
Mon Mar 17 14:37:00 EDT 2008
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.
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:
> def someattr(self):
> # get data from external source
> 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.
More information about the PEAK