Jeff,
Responses below:
Jeff Dyer wrote:
Re: ES4 work
>
“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.
Still a bit of a catch 22 for implementers.
What would help a great deal are unit tests and sample code for how the
features actually work. We've found that reading the builtins has
helped in many cases.
Is there a plan to develop unit tests cases that the implementations
can use?
> “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.
I've found the paper that Lars and others worked on to be very helpful,
but it was targeted at a broad audience. We find that we often drill
down questions that are not easily answered. For example: what is the
exact scope for function default parameter expressions, constructor
initializers etc. These were answered via Q&A, but not captured in
a systematic way for others with the same questions.
We need a way to capture clarifications and Q&A. Could we take a
copy of Lars's paper and perhaps extend as unanswered questions are
raised and answered. Then that Paper would become an excellent bridging
tool until the spec is written and available.
I would be happy to re-read and come up with questions that we have
that are still unanswered or unclear.
> “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.
Agree that those lists are not worth debating, but definitely worth
sharing. It would help sway some of our priority discussions.
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.
Agree. I'm very thankful for all the efforts that the group have
invested in the language. It is easy to come late to the party and not
understand the wisdom that has been expended in many conversations and
prior debates.
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.
Understand. We are happy with this risk. In fact, most implementations
will innovate at the edges. This is the way we gain real experience for
future drafts of the language.
> “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.
Could Graydon give a snapshot of what is not implemented in the RI in
terms of the proposals / features? I know the trac database lists all,
but a punch list of the high priority deficits would be helpful.
>”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 of implementation feedback you need?”
Two questions come to mind:
1 – do you understand the feature well enough to write a detailed
specification of it?
2 – are you willing to ship it as is (modulo bug fixes and performance
tuning)?
For #2, we are quite happy to risk shipping features prior to
standardization and we will do our very best to adapt, change and track
the standard. We are pretty up front with users on this front.
Regarding #1, I may not possess the skill to write specifications. My
skills are more as an implementer than a language designer and even
less as a writer. I find that I pale when compared to other more
leading lights in this regard.
>”Lastly, please don't interpret the above 2 issues as negative
feedback. I think this is a good and normal process for defining a
spec. We need to have real-world experience using these features to
prevent painful errors going forward.”
Thanks, no offense taken. On the contrary, I see the advanced ES4
implementation work you have done as a great asset that we need to
leverage. The process outlined here can be used by those with shared
values and vision to produce a strong specification that defines the
language of multiple implementations. It needs further refinement, but
mostly it just needs to be done.
Your welcome. We are looking forward to releasing our first snapshot
soon.
Michael
Jd
On 2/15/08 11:20 PM, Michael O'Brien wrote:
Jeff,
Thanks for outlining the process to go forward. Overall I like having
real implementations prove the value and feasibility of features and
proposals before they are poured in concrete. But I see 2 2 obstacles
that I outline below:
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.
I've been using the RI, Lars's paper and emailed questions to flesh out
my understanding of the proposals -- but my understanding is often
incomplete or inaccurate.
So my question is what are the agreed set of proposals and where are
they adequately documented?
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.
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.
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 of implementation feedback you
need?
Lastly, please don't interpret the above 2 issues as negative feedback.
I think this is a good and normal process for defining a spec. We need
to have real-world experience using these features to prevent painful
errors going forward.
thanks
Michael O'Brien
Mbedthis Software
Jeff Dyer wrote:
Hi,
We have entered a new phase in the development of the ES4 standard.
Since
September we have had a fixed set of proposals to consider individually
and
as a whole. The final step is to translate those proposals into
production
implementations and to document the language that results to become the
next
ES standard.
What follows is a high level description of the process that we (Adobe
and
Mozilla) feel should be followed to get from Proposals to a high
quality,
finished specification.
We should discuss this at our ES4-WG phone call this Tuesday (Feb-19).
Advanced comments welcomed.
WORKFLOW
The basic workflow:
Proposal -->
Implementation -->
Feature spec -->
Feature review -->
ES4-RI -->
ES4 spec -->
Proposal - see http://wiki.ecmascript.org/doku.php?id=proposals:proposals.
These proposals are the pool of possible feature proposals. Only
exceptional
circumstances will warrant a feature not covered by an accepted
proposal to
be considered.
Implementation - interested implementers collaborate on the
implementation
of a feature described by the proposals. This exercise should end with
one
or more implementations of the feature to provide feedback on usability
and
implementation complexity.
Feature spec - one of the participants from the implementation team
writes
up a description of the feature based on that implementation. Feature
specs
are complete and accurate descriptions of individual features to be
added to
the language. They are supported by production implementation, test
cases
and implementer commitment to release the feature.
Feature review - ES4-WG reviews the feature spec and implementation and
when
satisfied accepts the spec to be included in the ES4 spec.
ES4-RI - once accepted, the RI is checked for compatibility with the
production implementation and readability. Although the RI is used as a
kind
of prototype of the proposals, its primary purpose is aide in
understanding
and exposition of the language. This step involves preparing parts of
the RI
for inclusion in the spec.
ES4 spec - and finally, the ES4 draft is updated to include the accepted
feature and reviewed first by ES4-WG and then TC39.
IMPLEMENTATION TEAMS
The implementation teams will be ad hoc collaborations between two or
more
implementers. Ideally, at least one of those implementers is an Ecma
member
so that the feature has representation throughout the standardization
process.
ES4-WG AND TC39 MEETINGS
The ES4-WG meetings should focus on the review of feature specs and ES4
spec
drafts. Two weeks before each TC39 meeting a draft of the ES4 spec will
be
distributed for review by the TC39 members.
SCHEDULE
In order to be approved at the December 2008 GA, a final draft of the
ES4
spec must be ready for review at the Sep TC39 meeting. This is clearly
an
aggressive schedule, but one that is achievable given that high quality
feature specs are produced by several feature teams in parallel.
We envision at least two teams working in parallel on AS3-like features
and
JS1.7-like features.
Here is a very high-level schedule of deliverables to TC39
Mar - draft 1
- ES3 spec based on the ES4-RI
- Library spec
May - draft 2
- Core language mostly spec-ed
Jul - draft 3
- Spec complete
Sep - draft 4
- Final review
Oct - final draft
- Send to CC for approval
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
|
