Comments below: > > This sounds good, but if we've accepted proposals and need detailed > specs, why not write specs? This is not just a matter of wiki > namespace (proposal: vs. spec:). Proposals have emphasized precedents, > use-cases, and anti-use-cases, and considered alternatives. Discussion > uncovered further detail, but still not enough for a spec in all cases. >
The reason is we could remove a few road blocks with some design notes. These won't be as complete as the spec but could from the basis of writing some of the spec prose. > > Also, the spec can reference the RI (not just SML but, for the > standard library, the self-hosted ES4!) in a systematic way. Proposals > preceded the RI. The problem here is time. I think doing the spec with the required level of rigour will take much longer than would be ideal to get implementations started. > > Suggest we evaluate Lars's forthcoming library spec and see what > proposals pages it effectively updates. Agree we should mark those > pages somehow as superseded by specs, with links to the specs. Not > thrilled about leaving out-of-date proposals around, but there's > clearly a conflict between the wiki, which is great for content > creation, and the trac and spec, which are better for disposition and > finalizable specification. I've seen an early cut of the Library spec. Is an update coming? > Again I am leery of reinventing the RI in prose, duplicating its > meaning with added bugs and no testability. Better to refer to the RI > directly as I think you proposed earlier, or even excerpt it as was > planned for the spec. The ES4 excerpts should not need lowering; > Graydon's script can be used if people find SML hard to read. > Fine to refer to the RI, but I think we're talking notes here. Graydon's emails contain a lot of good "notes" but are certainly not a spec (yet). I think we just need more of those "notes". I would agree that if this can't be done simply and easily, we should just push on as forward momentum will eventually deliver the goods. Time is never a friend if we are slow or meandering. >> Create a common place to store resolutions and clarifications on >> issues. The mailing list isn't great for this gems get lost in the >> volume. Perhaps the author for each design note could maintain the >> document and append questions on the end as clarifications in wiki >> style. > > Tracking issues is a job for the trac, although there's always room > for on-the-side summaries linking to tickets, if you keep editing to > keep up with the primary source of truth in the trac. I think the summaries are where the gold is. That is the piece we are missing. We actually have a lot of information, but it is scattered and hard to put together in a coherent manner. > >> I'll start the ball rolling with writing up some notes on Program >> Units, use unit and unit dependencies. Brendan/Jeff: what format >> would you like these notes in? > You missed this question above. Cheers Michael _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
