[L2Ork-dev] feature-triggered specifications

[Jonathan Wilkes]

Hi list,I'd like to propose "feature-triggered specifications" for development of Purr Data.
If someone wants to implement a new feature to the language or environment, 
they need to write a clear specification for how that part of the language or 
environment currently works.  Once done, discussion of the proposed 
feature can start simply by showing how it changes (or newly written spec.

I've suffered from not having done that with the additions to data 
structure drawing.  It really eats at development time because it increases 
the chance of coding oneself into a corner.
For example: if we want to make it possible to save symbols with spaces 
in them to pd patches, we would need a spec for how Pd goes from 
FUDI to text and back.  That's a lot of work.  But it's also a lot of work to 
make a change to the parser that doesn't break things.  The best way to 
refrain from breaking things it to write down how things work.  So I propose 
we do that.
This wouldn't apply to crasher/UI bugs.  It might need to apply to deeply 
ingrained bugs, like the fact that you can cause dropouts by moving the 
mouse over a patch.

-Jonathan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20170329/ea07b339/attachment.html>