On Thu, Jan 30, 2014 at 1:20 PM, Forrest L Norvell <forrest at newrelic.com>wrote:

> On Thu, Jan 30, 2014 at 9:40 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>
>> On 1/30/14 8:25 AM, Domenic Denicola wrote:
>>
>>> since I find that style more precise and idiomatic
>>>
>>
>> It's not clear to me that the former is true (and in fact, making sure
>> that an ES-style spec is not fundamentally buggy in the "doesn't have the
>> desired behavior" sense is _much_ harder than doing it for a WebIDL spec,
>> in my experience).
>>
>> It's also _much_ harder to read and understand in my experience, and the
>> experience of many other people I've talked to.
>>
>
> I am going through the process of implementing Domenic's spec in ES5 for
> Node as a way of validating my understanding of the spec (in reality, the
> only Nodeisms in my implementation is my use of CommonJS modules), so maybe
> I can shed a little light on this.
>
> So far, this has been a very straightforward spec to implement. The spec
> language is imperative and concrete, so it is easy both to turn into
> JavaScript and to point to the correspondences between the implementation
> code and the relevant line items in the spec. So far, it has also been easy
> to use the code to illuminate inconsistencies or identify problems with the
> spec,
>

This is excellent, please be sure to file any spec bugs of any nature here:
http://bugs.ecmascript.org Feedback based on implementation experience is
critical to ES6 success :)

Rick


> and using the nomenclature of ES-262 makes very clear from context how to
> distinguish between the public interface of the API and its internal
> properties and methods.
>
> I've been surprised (and pleased) by how easy it has been to implement the
> spec thus far, and most of the issues I've raised with Domenic have been
> down to either minor misunderstandings on my part or judgment calls without
> objectively right or wrong answers. To me, this feels like the appropriate
> sort of issues to be coming out of working with a draft specification. Much
> of the credit for that goes to Domenic and his collaborators (and probably
> also to my familiarity with other JavaScript streams implementations), but
> I appreciate not having to spend a lot of time translating between WebIDL's
> abstract hybrid of C++, Java and JavaScript type models and the code I'm
> working on.
>
> As an implementor, I find this all a refreshing contrast to trying to wrap
> my head around WebIDL, which, in my blunt opinion, does a poor job of
> capturing any real operational model used on the web. 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), I think
> ECMASpeak is preferable to WebIDL.
>
> F
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140130/08b75e4b/attachment.html>

On Thu, Jan 30, 2014 at 1:20 PM, Forrest L Norvell <forrest at newrelic.com>wrote:

> So far, this has been a very straightforward spec to implement. The spec
> language is imperative and concrete, so it is easy both to turn into
> JavaScript and to point to the correspondences between the implementation
> code and the relevant line items in the spec. So far, it has also been easy
> to use the code to illuminate inconsistencies or identify problems with the
> spec,

This is excellent, please be sure to file any spec bugs of any nature here:
http://bugs.ecmascript.org Feedback based on implementation experience is
critical to ES6 success :)