RE: Selectors: name find method and find signature

From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU] 

> None of those affect the common pitfalls people run into.

Really? Argument defaulting and destructuring, at the very least, seems like something that's historically been done many different and un-ESey ways. As has been defining classes with constructors and classes that can be inherited from. What common pitfalls would you be thinking of?

> The benefit of using a declarative language is that it lets optimal-speed macro-code be generated for the various JS implementations...  This is not a benefit to throw away lightly.  As in, I expect UAs to continue to use such declarative languages internally no matter what the specs are doing.

Certainly. There's no desire to create something that's not useful to implementers. But, how would you declaratively specify something like "iterate over `iterable`, performing the following steps"? Or "let `returnValue` be `new this.constructor(1, 2, 3)`"? These are algorithmic pieces, not annotations to the return type or incoming arguments. As their side effects are observable, they often need to occur in the middle of algorithms, not up front.

I ask these questions in earnest, to be clear. I want a useful JSIDL, or WebIDL: The Evolution. What implementers want is a large part of that. So:

- What common pitfalls does WebIDL help you avoid, that fall outside the realm of class definitions/argument defaulting/argument destructuring/type coercions?
- How would you propose creating declarative forms for observable algorithmic steps?

Received on Friday, 13 September 2013 16:01:46 UTC