supporting ES upgrading with a programming pattern repo?

Claus Reinke claus.reinke at
Wed Nov 9 01:55:22 PST 2011

Both the committee and JS coders could profit from examples.

The committee wants to ensure that their design decisions lead
to improvements in language usage, JS coders want to know
what those semi-formal proposals mean for their day-to-day
use of the language. Both parties want to be sure that the new
proposals do not lead to nasty surprises when put together
and confronted with real-life code bases.

(as the @iter example shows, small tweaks might be needed
 even if no disasters loom anywhere)

Yet the committee cannot look at every JS code base out there
in any detail, and JS coders are not comfortable reading the
current spec, let alone a variety of subtly different proposals.

Could there be a repo  of programming patterns, where

- TC39 puts up new patterns they want to enable
    (patterns as examples or proposals in use)

- TC39 puts up old patterns they want to discourage,
    together with replacement patterns they want to
    encourage (patterns as transition help, demonstrating
    that no expressiveness is lost)

- JS coders submit patterns that they rely on, so that TC39
    can decide how those patterns may be affected by

- JS coders can browse the pattern repo to see what
    means for them, and whether their programming styles
    will be affected

This would not only help to communicate the design
decisions and discussions (if patterns are annotated with the
proposals they depend on, and proposals link to the patterns
that serve as positive and negative examples). 

It would also help TC39, to become aware of possible problem 
spots early, if we can get JS coders to get involved with such 
a pattern repo as a more accessible peek at the new design. 

- "I've been using 'with' like this - what should I do instead?"

- "I have a sequence of alternative module source locations, 
    to be tried in order until one succeeds - can I still do that 
    with modules?"

- "I rely on monkey patching and ES shims - how is that 
    going to work with modules?"

- ..

It might get more eyes looking through the effects of putting
current proposals into practice, instead of putting most of
that responsibility on a single spec editor. That implies that
the repo should be a wiki, or a github repo editable by all
TC39 members (at least).

What do you think?



More information about the es-discuss mailing list