From: Boris Zbarsky [mailto:bzbar...@mit.edu]
> Consider this IDL:
>
> dictionary Dict1 {
> long a = 5;
> };
>
> dictionary Dict2 {
> sequence dicts;
> }
>
> void foo(optional Dict2 arg);
>
> How would you express eqivalent semantics with destructuring?
```js
function foo({ dic
On Fri, Sep 13, 2013 at 5:01 PM, Domenic Denicola
wrote:
> Or "let `returnValue` be `new this.constructor(1, 2, 3)`"?
We already define the return type in IDL. If the return type equals
the class type we could have an annotation that indicates it uses
this.constructor vs it using new.
The filter
On 9/13/13 3:19 PM, Domenic Denicola wrote:
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
Consider this IDL:
dictionary Dict1 {
long a = 5;
};
dictionary Dict2 {
sequence dicts;
}
void foo(optional Dict2 arg);
How would you express eqivalent semantics with destructu
On 9/13/13 2:46 PM, Domenic Denicola wrote:
Thanks Boris, this is indeed all very helpful. I just wanted to point out that what you are calling
"dictionaries" is largely covered by what I called "destructuring," on the
input side at least. E.g.
Furthermore, privileged code should never be wor
Thanks Boris, this is indeed all very helpful. I just wanted to point out that
what you are calling "dictionaries" is largely covered by what I called
"destructuring," on the input side at least. E.g.
> Furthermore, privileged code should never be working with raw page-provided
> ES objects, be
From: Boris Zbarsky [mailto:bzbar...@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 cons
On 9/13/13 12:01 PM, Domenic Denicola wrote:
Really? Argument defaulting and destructuring, at the very least
Is typically not used in web specs until very recently.
As has been defining classes with constructors and classes that can be
inherited from.
Classes with constructors, agreed. M
On 9/13/13 11:50 AM, Boris Zbarsky wrote:
As in, I expect UAs to continue to use such declarative languages internally no
matter what the specs are doing.
And if the expectation is correct, there is value on only doing the
mapping from behavior to declarative once in the open instead of each U
On 9/13/13 11:22 AM, Domenic Denicola wrote:
Ideally, ES6 will give most of the "macros" needed, in the form of class
syntax, default arguments, and destructuring argument lists. It's not all you need,
certainly, but it does obviate a lot of WebIDL
None of those affect the common pitfalls peo
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
>> TC39 and like-minded people are pushing in the direction of the platform
>> being mostly a JavaScript library which would indeed give you exactly those
>> problems...
> Why?
> There is no reason we can't have macros for commonly used ES-style p
On 9/13/13 10:58 AM, Anne van Kesteren wrote:
On Fri, Sep 13, 2013 at 3:53 PM, Boris Zbarsky wrote:
OK, fwiw I think I agree. The next question is whether they should be
generic in the elements of the collection or not too.
I don't really follow this. Are you talking about
Element.prototype.
On Fri, Sep 13, 2013 at 3:53 PM, Boris Zbarsky wrote:
> OK, fwiw I think I agree. The next question is whether they should be
> generic in the elements of the collection or not too.
I don't really follow this. Are you talking about
Element.prototype.query? That should probably mimic other method
On 9/13/13 10:49 AM, Anne van Kesteren wrote:
On Fri, Sep 13, 2013 at 3:22 PM, Boris Zbarsky wrote:
In any case, my real questions revolve around generic vs branded methods and
whatnot, which are not covered by those two bugs.
I think they should be generic
OK, fwiw I think I agree. The ne
On Fri, Sep 13, 2013 at 3:22 PM, Boris Zbarsky wrote:
> In any case, my real questions revolve around generic vs branded methods and
> whatnot, which are not covered by those two bugs.
I think they should be generic, just like the methods on Array which
this object inherits from. That's why we wa
On 9/13/13 4:14 AM, Anne van Kesteren wrote:
There's two IDL bugs referenced from the specification that have
public-script-coord copied. What am I missing?
Hmm. I didn't see those bugmails go by; maybe they got filtered out by
my "html bugs" filters. :(
In any case, my real questions revo
On Thu, Sep 12, 2013 at 4:19 PM, Boris Zbarsky wrote:
> I would appreciate some discussion on public-script-coord about the IDL
> stuff you're making up here.
There's two IDL bugs referenced from the specification that have
public-script-coord copied. What am I missing?
(One even questions using
On 9/12/13 10:27 AM, Anne van Kesteren wrote:
http://dom.spec.whatwg.org/ now includes these methods as well as the
new Elements return value
I would appreciate some discussion on public-script-coord about the IDL
stuff you're making up here.
-Boris
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
> Why is that needed? If we just want this to be generic and all, it seems
> simplest to say that they just get the "length" of "this", then run a counter
> from 0 to length, for each value [[Get]] that property, then [[Invoke]]
> "querySelectorAl
On 9/12/13 1:09 PM, Domenic Denicola wrote:
Hmm, the issue is, this internal-properties thing is pretty prevalent in ES6
generally. All the built-ins can now be subclassed, and the mechanism in the
spec for that is by giving them internal data properties that are initialized
by their @@create,
On 9/12/13 11:19 AM, Boris Zbarsky wrote:
On 9/12/13 10:27 AM, Anne van Kesteren wrote:
http://dom.spec.whatwg.org/ now includes these methods as well as the
new Elements return value
I would appreciate some discussion on public-script-coord about the IDL
stuff you're making up here.
And in
On 9/12/13 12:38 PM, Domenic Denicola wrote:
One idea we had for this was as outlined in the gist at [1], where they try to call some
internal "[[QuerySelectorAll]]"-like method of things contained within it
Why is that needed? If we just want this to be generic and all, it
seems simplest to
On 9/12/13 12:57 PM, Domenic Denicola wrote:
That sounds cool too! I was just concerned it wouldn't be optimizable enough.
I think it depends on what you mean by "enough".
Getting properties out of an array is much faster in script (e.g.
self-hosted) than it is via the C++ API, at least for S
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
> I think it depends on what the "internal properties" bit is and how flexible
> it's supposed to be.
> For example, if in this case the basic operation would be to check for a C++
> Element instance and then call some C++ method with that instance
> And in particular, the spec as written now doesn't clearly define the
> behavior of query() or queryAll(). Presumably they would be defined in some
> generic way (such that they can run with any object as "this"), but it's not
> obvious what that generic way is in this case. This seems like
On Wed, Sep 11, 2013 at 12:27 PM, Anne van Kesteren wrote:
> If we are going to return an Array subclass as the new way to
> represent a collection of Element objects, we cannot use the name find
> as it is already used by Array. select and selectAll would be better
> names.
We decided on query()
On Wed, Sep 11, 2013 at 12:27 PM, Anne van Kesteren wrote:
> If we are going to return an Array subclass as the new way to
> represent a collection of Element objects, we cannot use the name find
> as it is already used by Array. select and selectAll would be better
> names.
has select(). Domeni
On Wed, Sep 11, 2013 at 6:20 AM, Domenic Denicola
wrote:
> From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
>
>> That helps when you've *already* run findAll() once, and need to run it
>> again on the results, but it doesn't help at all when you're starting with a
>> set of elements, unless we
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
> That helps when you've *already* run findAll() once, and need to run it again
> on the results, but it doesn't help at all when you're starting with a set of
> elements, unless we perhaps make a constructable NodeList and force people to
> p
On Wed, Sep 11, 2013 at 12:39 PM, Tab Atkins Jr. wrote:
> That helps when you've *already* run findAll() once, and need to run
> it again on the results, but it doesn't help at all when you're
> starting with a set of elements, unless we perhaps make a
> constructable NodeList and force people to
On Wed, Sep 11, 2013 at 4:27 AM, Anne van Kesteren wrote:
> If we are going to return an Array subclass as the new way to
> represent a collection of Element objects, we cannot use the name find
> as it is already used by Array. select and selectAll would be better
> names.
Agree.
> In http://kr
30 matches
Mail list logo
