Re: JavaScript Language feature Idea

> On Apr 19, 2016, at 1:40 AM, Jordan Harband wrote: > ... > I think Array#get/Array#set are the most reasonable suggestions offered so > far, but I don't think the added value will be enough to convince the > committee that it's worth adding to the already large API surface

Re: JavaScript Language feature Idea

> > And Set by definition is an unordered collection, so there is no "last" > element. Sets in ES6 are iterated in insertion order. I don't think a .get or .set needs to be made for Array. Why would you use `arr.set(1, 4)` over `arr[1] = 4`, and why should there be more ways of doing the same

Re: JavaScript Language feature Idea

2016-04-19 10:40 GMT+02:00 Jordan Harband : > (note that `Set#get(-1)` does not retrieve the last item in the set, for > example). > Because Set.prototype.get doesn't even exist. And Set by definition is an unordered collection, so there is no "last" element. I think

Re: JavaScript Language feature Idea

Let's not cry doomsday because there's not an easy path to adding "-1" array access, when indexing into a list of things *in the first place* is already a potential code smell. `endsWith` was able to be added because *it didn't break anything*. `contains` was renamed to `includes` because the

Re: JavaScript Language feature Idea

If we're talking about adding a new method anyway, why not just add a more general `get` method with support for both positive and negative indices? That would be consistent with the other array methods, and additionally I think it is more natural to use `arr.get(-2)` than `arr.last(1)`. Using

Re: JavaScript Language feature Idea

Adding `last` to `Array.prototype` is no different than adding `endsWith` to `String.prototype`. ES2015 did it. It won't break most existing code that defines `Array.prototype.last`. Such code will just overwrite the new `last` method and will continue to work as before. You won't be able to mix

Re: JavaScript Language feature Idea

This is why we can't have nice things... Literally anything we do with the language *at all* can collide with libraries. Introducing new syntax? Code that was using eval and throwing syntax errors is now behaving differently and you 'broke the web'... Adding a `Symbol.last` method to `Array#`?

Re: JavaScript Language feature Idea

Please go back and read the existing threads. We've been over this territory ad nauseum. Yes, of course `array[-1]` would break the web and that's why no one is seriously proposing that. As already discussed extensively, `Array#last` may be an option, but it could collide with libraries or other

Re: JavaScript Language feature Idea

Why new syntax here? This is just a method that's missing: `array.last(n)`. `array[-1]` would break things and it is difficult to find out where. Consider: ``` javascript for (var i = array.length - 1; array[i]; i--) doSomething(array[i]); ``` Not the best way to write such a loop but changing

Re: JavaScript Language feature Idea

Although there seems to have been a decisive lack of interest in my extended pick notation proposal, it cleanly subsumes the entire idea of "lastElement" and its endless rehashed variations involving new prototype methods or symbols or whatever else people proposed. In my proposal, "lastElement"

Re: JavaScript Language feature Idea

I assume if you were to spec out the additional syntax you'd go the whole hog and add ranges, e.g. arr[:-4, -2]; Like I said, not particularly compelling as it's not a huge saving over slice() and selecting single negative indices can be done with Proxy. On Mon, 18 Apr 2016 20:32 Michael

Re: JavaScript Language feature Idea

This can be trivially done with proxies. I don't think arrays should have a special trap dependent on whether or not a symbol is set. If I were to make a custom array with proxies I would then have to check if someone changed standard behavior by inserting a symbol, and pass the symbol to the

Re: JavaScript Language feature Idea

I don't think that would be trivial to implement and there might not be a common enough use case for it. You might want to look into something like http://sweetjs.org if it's the syntactic sugar you're looking for. On Mon, 18 Apr 2016 19:35 /#!/JoePea, wrote: > > ```js > >

Re: JavaScript Language feature Idea

`Symbol.implementation` should be fairly trivial to implement once [Realm](https://github.com/caridy/proposal-realms)s are around, without affecting global scope. On Montag, 18. April 2016 18:58:06 CEST Andy Earnshaw wrote: > I don't think that would be trivial to implement and there might not

Re: JavaScript Language feature Idea

> ```js > Array[Symbol.implementation] = MyArray; > ``` > That would mean all other programs executing on the page would be forced to > use that Array implementation And also with my suggestion that would impact all code too. Would it be possible to limit the effect of using certain symbols to

Re: JavaScript Language feature Idea

That would mean all other programs executing on the page would be forced to use that Array implementation, imposing potentially critical problems with, for example, performance and expected behavior. It's just not a good idea. I missed off esdiscuss when I replied earlier, but I mentioned that

Re: JavaScript Language feature Idea

Yes, now we're heading in the right direction. The problem with something like `Symbol.propertyAccess` is that this might lead to a flood of new well-known Symbols. Conceptually, `Symbol.propertyAccess` sounds like it should have been a `Proxy` trap, anyway. Here's an more general idea: Why

Re: JavaScript Language feature Idea

But, can ```js let a = [1,2,3] ``` create a new MyArray? Maybe, instead of having negative indices by default (which breaks some backwards compatibility) we can introduce a symbol for overriding property access? Something like ```js Array.prototype[Symbol.propertyAccess] = function(index) {

Re: JavaScript Language feature Idea

I don't see a good reason why to mangle with this. Note that you can achieve this behavior without breaking backwards compatibility with ES6 Proxies: ```js class MyArray extends Array { constructor(...args) { super(...args); function

Re: JavaScript Language feature Idea

Backwards compatibility has been broken before. I don't think this one is too bad of a breakage. On Sun, Apr 17, 2016 at 9:48 PM, Biju wrote: > On 17 April 2016 at 17:29, Frankie Bagnardi wrote: >> That would break backward compatibility; >> >>

Re: JavaScript Language feature Idea

On 17 April 2016 at 17:29, Frankie Bagnardi wrote: > That would break backward compatibility; > > ```js > var a = ['a']; > a['-1'] = 'test'; > Object.keys(a) // ['0', '-1'] > ``` Do we have statistics how many sties depend on that?

Re: JavaScript Language feature Idea

That would break backward compatibility; ```js var a = ['a']; a['-1'] = 'test'; Object.keys(a) // ['0', '-1'] ``` On Sun, Apr 17, 2016 at 11:53 AM, Biju wrote: > We cam make this simpler, in Javascript Array.slice() already accept > negative index. > Developers from

Re: JavaScript Language feature Idea

We cam make this simpler, in Javascript Array.slice() already accept negative index. Developers from Javascript and other languages are familiar with negative value for index parameter. So why cant we make array accept negative index. in comparison with Bob Myers' proposal > ``` > [1,2,3](-1) >

Re: JavaScript Language feature Idea

Another possibility is `Array.prototype.get()`, which would be in line with ES6 Maps. > On 02 Feb 2016, at 21:15, Jonas Sicking wrote: > > On Mon, Jan 25, 2016 at 12:38 PM, Andrea Giammarchi > wrote: >> FWIW `.at` works for me. Anything really,

Re: JavaScript Language feature Idea

On Tue, Feb 2, 2016 at 12:15 PM, Jonas Sicking wrote: > On Mon, Jan 25, 2016 at 12:38 PM, Andrea Giammarchi > wrote: >> FWIW `.at` works for me. Anything really, as long as `Symbol.last` won't >> even be proposed :D > > If we name it `.item` that

Re: JavaScript Language feature Idea

On Mon, Jan 25, 2016 at 12:38 PM, Andrea Giammarchi wrote: > FWIW `.at` works for me. Anything really, as long as `Symbol.last` won't > even be proposed :D If we name it `.item` that would mean that a whole bunch of DOM classes could be replaced with plain JS Arrays.

Re: JavaScript Language feature Idea

``` [1,2,3](-1) ``` I will not beat this dead horse further, and it may be visually undesirable, and/or hard to implement, but for what it's worth, the idea is not to make arrays callable; it's just new syntax to allow parenthesized expressions following arrays, which would be interpreted as an

Re: JavaScript Language feature Idea

FWIW `.at` works for me. Anything really, as long as `Symbol.last` won't even be proposed :D On Mon, Jan 25, 2016 at 9:33 PM, Caitlin Potter wrote: > Nitpicking here, but the `nth` method is traditionally named `at`, if it > were going to be formally proposed > > On Jan

Re: JavaScript Language feature Idea

`Array.prototype.nth(n=0)` looks great indeed, +1 here About the Symbol ... ugly as hell also we need to write even more and it doesn't scale as utility compared to .nth ```js a[Symbol.last] a[a.length-1] ``` I mean, seriously ... don't even consider that or someone might ask to implement

Re: JavaScript Language feature Idea

Nitpicking here, but the `nth` method is traditionally named `at`, if it were going to be formally proposed > On Jan 25, 2016, at 3:00 PM, Andrea Giammarchi > wrote: > > `Array.prototype.nth(n=0)` looks great indeed, +1 here > > About the Symbol ... ugly as hell

RE: JavaScript Language feature Idea

I oppose the Symbol approach. It makes code looks ugly just for adding write access. There is already a `.push()`, and we only need to add `.last()` or `.back()` to make it complete. > From: k...@kdex.de > If it comes to write access, I agree that`Symbol.last` could be another > handy >

Re: JavaScript Language feature Idea

On 01/25/2016 12:00, Andrea Giammarchi wrote: `Array.prototype.nth(n=0)` looks great indeed, +1 here About the Symbol ... ugly as hell also we need to write even more and it doesn't scale as utility compared to .nth ```js a[Symbol.last] a[a.length-1] ``` I fail to see the point of this,

Re: JavaScript Language feature Idea

The syntactical construct `array()` is unused as far as I know, since currently it would always generate a syntax error--an array is not a function. Thus we can use this as in ``` [1,2,3](-1) ``` Shouldn't break anything. Bob On Tue, Jan 26, 2016 at 2:08 AM, Andrea Giammarchi <

Re: JavaScript Language feature Idea

Bob Myers schrieb: The syntactical construct `array()` is unused as far as I know, since currently it would always generate a syntax error--an array is not a function. It's a runtime `TypeError` rather. Thus we can use this as in ``` [1,2,3](-1) ``` Shouldn't break anything. This would

Re: JavaScript Language feature Idea

Not sure if you are talking about Array.prototype or Symbols but whatever worry you have is identical. Having a Symbol in the prototype or adding a method ... I don't see much difference. Which one is best? History shows it's the method. It plays well, it's easy to polyfill, no complexity added

Re: JavaScript Language feature Idea

> [1,2,3](-1) But it implies a function call, which isn't the case. It could possibly be confusing when reading code. On Mon, Jan 25, 2016 at 1:04 PM, Bob Myers wrote: > The syntactical construct `array()` is unused as far as I know, since > currently it would always generate a

Re: JavaScript Language feature Idea

On Sat, Jan 23, 2016 at 12:46 PM, kdex wrote: > @Michał: That really depends on the point of view: If you need zero-based > indexing from the right, as `[]` does from the left, you'd use > `Array.prototype.last`. > > On Samstag, 23. Januar 2016 20:56:02 CET Michał Wadas wrote: >> I

Re: JavaScript Language feature Idea

On Sat, Jan 23, 2016 at 12:54 PM, kdex wrote: > [1, 2, 3].last(); // 3 I'm wondering what the ultimate motivation for suggestions like this is. Is it to save key strokes? Allow more semantic coding? Support new paradigms? Performance? 'm sure someone has already come up with

Re: JavaScript Language feature Idea

Not every feature addition is due to performance or paradigms. Just have a look at ES2015: I'm sure that this has neither been the motivation for `String.prototype.startsWith`nor for `String.prototype.includes`. Even `String.prototype.repeat` appears so simple that a loop paired with a

Re: JavaScript Language feature Idea

I can't consider `.last(1)` method to be readable... But I think `.nth(n)` method with support for negative index would be really useful. 2016-01-23 17:32 GMT+01:00 kdex : > Not every feature addition is due to performance or paradigms. Just have a > look at ES2015: I'm sure that

Re: JavaScript Language feature Idea

Just a short note: > I was not aware that it was an explicit design goal to simplify things for > people coming from other languages. Well, it most certainly was. That's why we're "blessed" with ASI. :) On Samstag, 23. Januar 2016 23:41:45 CET you wrote: > I can't remember the last time I

Re: JavaScript Language feature Idea

@Michał: That really depends on the point of view: If you need zero-based indexing from the right, as `[]` does from the left, you'd use `Array.prototype.last`. On Samstag, 23. Januar 2016 20:56:02 CET Michał Wadas wrote: > I can't consider `.last(1)` method to be readable... > But I think

Re: JavaScript Language feature Idea

Freedom of choice for the win. I like it. On Sat, Jan 23, 2016 at 12:46 PM, kdex wrote: > @Michał: That really depends on the point of view: If you need zero-based > indexing from the right, as `[]` does from the left, you'd use > `Array.prototype.last`. > > On Samstag, 23. Januar

Re: Javascript Language feature Idea

Standardizing unused array keys breaks compatibility about as much as extending the prototype does, really. Users can already mangle with both. The problems are a little more subtle, and yes, it would severely break backwards compatibility. Consider this example (accessing an element based on

Re: Javascript Language feature Idea

I really adore the slicing syntax. Just as a quick fix, though, > arr[begin,]; // => arr[begin, arr.length]; should obviously return `arr[begin, arr.length - 1]`. Honestly, I'm not too sure if the "easy push" syntax is particularly self- explanatory. There might be better alternatives. On

Re: Re: Javascript Language feature Idea

More cool stuff: ```javascript const arr = [1, 2, 3]; // Easy push arr[] = 4; // => arr[arr.length]; // Easy s(p)lice arr[begin, end];, arr[begin,]; // => arr[begin, arr.length]; arr[begin, end] = [1, 2, 3]; ``` A terrible example (terrible because this should be done with WebGL shaders):

Re: Javascript Language feature Idea

Interesting! More pedestrian, it would be nice to finally have a version of splice that doesn't create a new other Array as a side effect. > On Jan 22, 2016, at 13:00, kdex wrote: > > I really adore the slicing syntax. Just as a quick fix, though, >> arr[begin,]; // => arr[begin,

Re: Javascript Language feature Idea

Since Array inherits from Object, it can have any key, including the key "-1". So something like list[-1] would break compatibility as users can now already assign values to the index -1. If you want a short way to access the last element, it should probably be a function in the Array prototype.

Re: Javascript Language feature Idea

Don't forget that Array#slice() can accept negative indexes. E.g.: > ['a', 'b', 'c', 'd'].slice(-1) [ 'd' ] Which is nearly as terse as any Array.prototype addition would be, and I think it's at least expressive enough to alleviate the need for one. On Fri, Jan 22, 2016 at 12:59 PM, Sander

Re: Javascript Language feature Idea

On Fri, Jan 22, 2016 at 9:53 AM, RacerD123 wrote: > In other programming languages such as python, you can specify the last > element of a list with "list[-1]" but in javascript you have to do > "list[list.length-1]". Is there maybe a way to make this feature in >

Re: Javascript Language feature Idea

Personally I prefer a well known symbol for marking you are grabbing from the end of the list rather than this wrapping behavior like D ( https://dlang.org/spec/arrays.html#array-length ). That said I think `.last` is more reasonable than changing prototypes. On Fri, Jan 22, 2016 at 1:17 PM,

Re: Re: Javascript Language feature Idea

The "easy push" syntax exists in PHP so it will be familiar to at least some people. The slicey thing was also being discussed for PHP. I don't know if it landed or got dropped. ___ es-discuss mailing list es-discuss@mozilla.org

Re: JavaScript Language feature Idea

@Thomas: I think your implementation has a bug for negative values of n. It should have been `+ n` instead of `-n`, probably. To me, It would feel a little more "natural" if it behaved somewhere around this: ```js /* Used like the [] operator, but indices are counted from right to left and

Re: JavaScript Language feature Idea

t submissions to >> es-discuss@mozilla.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://mail.mozilla.org/listinfo/es-discuss >> or, via email, send a message with subject or body 'help' to >> es-discuss-requ...@mozilla

Re: JavaScript Language feature Idea

gt; > > > To subscribe or unsubscribe via the World Wide Web, visit > > > > https://mail.mozilla.org/listinfo/es-discuss > > > > or, via email, send a message with subject or body 'help' to > > > > es-discuss-requ...@mozilla.org >

Re: JavaScript Language feature Idea

Is this what you're thinking? Array.prototype.nth = function (n){ if(n < 0){ return this[this.length -n]; } else { return this[n]; } } Thomas Foster @thomasfoster96 Ph: +61477808008 http://thomasfoster.co/ > On 23 Jan 2016, at 4:40 PM, kdex wrote: > > While John's

Re: JavaScript Language feature Idea

Subject line so it is more specific > than "Re: Contents of es-discuss digest..." > > Today's Topics: > > 1. Re: JavaScript Language feature Idea (kdex) > 2. Re: JavaScript Language feature Idea (Thomas) >3. Re: JavaScript Language feature Idea (/#!/JoePe

Javascript Language feature Idea

In other programming languages such as python, you can specify the last element of a list with "list[-1]" but in javascript you have to do "list[list.length-1]". Is there maybe a way to make this feature in javascript? ___ es-discuss mailing list

Re: JavaScript Language feature Idea

more specific > than "Re: Contents of es-discuss digest..." > > Today's Topics: > > 1. Re: Javascript Language feature Idea (Bradley Meck) > 2. Re: Re: Javascript Language feature Idea (Alican ?ubuk?uo?lu) > 3. Re: Javascript Language feature Idea (kdex) >