implementation dependencies (was Re: ES4 work)
brendan at mozilla.org
Thu Feb 21 23:26:41 PST 2008
On Feb 21, 2008, at 11:07 PM, Michael O'Brien wrote:
> Seems to me we may have some emerging agreement on the following
> items. Please be kind if I'm overstating the consensus, but I
> believe the following items start us in the right direction without
> being too onerous.
> Triage the existing proposals into those that are current and
> correct and those that aren't. Publish that list.
> Bring the out-of-date proposal pages up to date
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.
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.
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
> Implementers & designers pitch in and write up design notes for
> proposals. This is then both input to the spec and immediate
> guidance for implementers.
> Some doc/comments for the RI
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.
> 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
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'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?
Graydon and Lars should weigh in too.
More information about the Es4-discuss