Hi Michael,
Thanks for your comments and questions. I¹ll try to address them here, and
hopefully you¹ll be able to join us on the next Tuesday phone call so we can
further flush out the issues.
³1. What actually are the proposals?²
³Many of those proposals on the Wiki are dated and much water has gone under
the bridge on these proposals since they were first made. Many conversations
have been had with sometimes subtle and sometimes not so subtle changes to the
meaning of those proposals. This presents a real problem for implementers in
understanding exactly what has been proposed and what is the meaning of the
proposals. For those who were present in those conversations and meetings may
have it all committed to memory, but those who have not present will certainly
struggle to gain a clear and exact understanding, as I do.²
You are correct in saying that the proposals don¹t all stand on their own.
This is the problem we intend to solve by requiring production
implementations to support complete and accurate feature specifications.
Each proposal carries with it a significant context, more or less captured
in meeting notes, trac tickets, the RI, and various people¹s heads. The
implementation focus will have two important effects: 1/force the
translation of proposals (by those with the necessary context to do so) into
implementations and feature specs that will stand on their own; 2/give
everyone else specific interpretations of those proposals to respond to.
³So my question is what are the agreed set of proposals and where are they
adequately documented?²
The agreed set of proposals are the ones posted on
http://wiki.ecmascript.org. Adequate documentation is what we intend to
produce, along with the all important agreement about what can and should be
implemented in our products. Admittedly we have a bit of a bootstrapping
problem here: we need to implement to know what we have agreed to, and we
need to understand what we agreed to to implement. But with the right people
working together I am confident that this cycle can be broken.
³A related question that exacerbates this problem is what has become of the
discussion to trim / streamline some of the feature set. As implementers, we
don't want to spend time implementing features that are not likely to be in the
final spec.²
An important side effect of an implementation focus is the prioritization of
features. There is a core set of well understood features that I believe we
need to include for the language to support itself (e.g. the built-ins). On
the other hand most of us have a list of features we could live without, or
believe are not sufficiently baked to qualify for standardization. Those
lists should be shared and guide our individual investments in
implementation, but I don¹t think they should take priority over real world
experience implementing and using the language. And I absolutely don¹t want
to spend my time debating the content of those lists until we have
implementation and user experience to ground that debate.
A huge amount of time and (inspired) effort has gone into creating the
current set of proposals. We need to be careful to protect that investment
by following a process that allows viable features to take root and others
to naturally wither and die.
As early implementers we necessarily run the risk of implementing features
that don¹t make it into the standard. On the other hand, we learn before
others what works and what doesn¹t. Again the point of this exercise is to
leverage that experience to get the language as close to right as possible.
³2. The RI is a key implementation too.
In your work flow, the RI seems to lag the implementations and you say it
has a role in prototyping features. But it has been filling a crucial role
in clarifying what the proposal was really meant to do. This goes beyond
prototyping. I regard the RI as the first implementation and the last. The
first, in the sense that it should define how the features are meant to
function and guide implementers and prevent many blind alleys. The last in
the sense, that it defines the spec. I'd like to stress that it must
continue to lead in implementing all key features.²
Admittedly I was doing a little hand waving here. Clearly the RI has given
us early insight into the language design, forced issues to the surface
sooner rather than later, and given us a model to play with. And in terms of
feature scope, the RI is fairly complete (thanks mostly to Graydon). The
point of the workflow is to show when key milestones are reached. In this
end game plan, here really isn¹t a clear and useful milestone associated
with the initial implementation in the RI. We could define one but that
might just add unnecessary overhead to the process. I see the current RI as
a part of that bundle of materials we call Proposals.
²Your timeline below does not indicate the kind of implementation readiness you
need to make this work flow actually work. Can you detail what kind
