Re: Array.prototype.contains
Would Array.prototype.removeAll(element); be worth considering? In the same vein as querySelector/querySelectorAll? On Wed, Jul 23, 2014 at 4:05 PM, Alex Vincent wrote: > On Wed, Jul 23, 2014 at 2:00 PM, Michael Haufe > wrote: > >> Array.prototype.removeAt(index); >> Array.prototype.remove(element); >> > > We already have an equivalent of removeAt: Array.prototype.splice(index, > 1). My concern about remove still stands. > > -- > "The first step in confirming there is a bug in someone else's work is > confirming there are no bugs in your own." > -- Alexander J. Vincent, June 30, 2001 > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.contains
Additionally, .contains() can be used in a conditional statement directly, while .indexOf() requires the result of a comparison with -1 (or a bitwise inversion, which is not terribly intuitive). It's just more room for simple typos. Will Ray On Wed, Jul 23, 2014 at 5:29 AM, Maël Nison wrote: > Isn't replacing DOMStringList a different issue than adding > Array.prototype.contains ? > > Using indexOf is possible, but a .contains() method would give a stronger > notice of intent when reading code. > > > On 7 March 2014 15:11, Boris Zbarsky wrote: > >> On 3/6/14 6:15 PM, Joshua Bell wrote: >> >>> FWIW, Blink uses DOMStringList only in IndexedDB and apparently in >>> Location.ancestorOrigins >>> >> >> Indeed. And Location.ancestorOrigins is fairly new and not broadly >> implemented, so I don't expect its behavior to be a strong compat >> constraint. >> >> So I guess that leaves us with a few questions: >> >> 1) Is it still early enough in the indexeddb world that we can change >> the thing it uses from DOMStringList to Array. And if so whether that's a >> change we want to make. >> >> 2) If we want to keep the non-writing behavior for indexeddb or for some >> other reason (insufficiently flexible bindings systems?) can't switch ti to >> Array for now, can we just remove item() and contains() from DOMStringList >> to make the switch easier later? >> >> >> -Boris >> ___ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > > > > -- > Maël Nison (arcanis <https://twitter.com/arcanis>) > Frontend Developer @ Sketchfab > > > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: for-loops and declaration-like init expressions
Mark, could you explain how the condition and iteration statements in the
for loop interact with such an initialization? I agree that banning these
seems like the clearer way to go.
On Thu, Jun 5, 2014 at 10:17 AM, Mark S. Miller wrote:
> Why not accept these as for-loop initializations, so that x actually has
> that function and that class as its initial value in the first iteration of
> the loop? To me, that's the least surprise. Since this is a position in
> which some declarations are accepted, anything there that looks like a
> declaration should be a declaration.
>
> However, I agree that banning these is much less surprising than allowing
> them as expressions rather than declarations.
>
>
>
> On Thu, Jun 5, 2014 at 7:58 AM, Andreas Rossberg
> wrote:
>
>> C-style for-loops allow declarations as init statements, but only some
>> of them. Yet, the others (function and class) are actually
>> syntactically legal in that position as well, because they are simply
>> parsed as expressions. Consider:
>>
>> let x = 0
>> for (let x = 1; ;) x // 1
>> for (const x = 1; ;) x // 1
>> for (function x(){}; ;) x // 0
>> for (class x(){}; ;) x // 0
>>
>> I think these latter two examples violate the principle of least
>> surprise. I wonder if it wouldn't be cleaner to rule them out, by
>> imposing the same lookahead restrictions on for-loop init expressions
>> as there are for expression statements.
>>
>> The one caveat is that for function, that would actually be a breaking
>> change, but is it likely to be a real world one?
>>
>> What do you think?
>>
>> /Andreas
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> --
> Cheers,
> --MarkM
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
