On 1/30/14 10:20 AM, Forrest L Norvell wrote:
So far, this has been a very straightforward spec to implement.
Forrest,
I think I may have been a bit unclear, my apologies.
I think we all agree that ES-style specifications are in fact more
straightforward to transcribe into an ES implementation.
What is harder, in my experience, is understanding whether the
specification actually says what it means to say and determining whether
there are bugs in the specification. This arises to some extent from
the core functionality being partially obscured by a fair amount of
boilerplate.
Now I agree this is somewhat subjective. Some people prefer to have all
the complications explicitly written out, both in specifications and in
code, while others prefer reusable tested black boxes that have certain
defined behavior. The former approach is much more verbose and can thus
hinder understanding of the big picture. The latter approach involves
in-depth understanding of the black boxes to understand the details. In
practice, both the WebIDL and ES styles use some mixture of the two;
what differs is the exact set of black boxes used. The ES style black
boxes are mostly more fine-grained than the WebIDL ones.
I wish I had a good way to combine the strengths of the two approaches
more than existing specification formalisms do right now. In some ways,
something that allows looking at higher-level definition in terms of
black boxes and then on-demand (e.g. a "expand this" or "expand all in
this section" link) allows the reader to inline the black boxes to see
all the details might be a possibility. That would involve creating
some tooling, obviously.
As an implementor, I find this all a refreshing contrast to trying to
wrap my head around WebIDL
I honestly think that this (just like other people's experiences with
trying to wrap their heads around ECMASpeak) is at least partially due
to familiarity, or lack thereof, with the black boxes being used as
specification primitives... Partially it may be due to the wrong
primitives being used, of course, which is a real problem in both styles
I believe.
I have nothing against formal specification methods per se, but, at least for
things
that are implementable in pure JavaScript (as Domenic's proposal is)
It's not, actually, since it requires asynchronous callbacks which do
not currently exist in pure JavaScript. This is not quite a nitpick,
since properly defining asynchronous callbacks is a fairly nontrivial
matter with security implications, as I already pointed out in this thread.
-Boris
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
