JsArray* to implement ECMAScript-262 methods

[dankurka]

Originally reported on Google Code with ID 2793

Found in GWT Release:
1.5 RC2

Detailed description:
JsArray* classes only have length(), get(int) and set(int, ?) methods while
ECMAScript-262 defines many more, namely: concat, join, pop, push, reverse,
shift, slice, sort, splice and unshift.

Attached is how it would look like (untested, lacking javadoc and with
private methods interleave with public ones, but you get the idea) for
JsArray<T>.

Workaround if you have one:
DIY in another class, as it's all JSNI or in some cases "emulation" for the
Hosted Mode.

Note that I didn't use Array.prototype to access Array methods (what's done
today in GWT's ArrayList emulation), as I heard there might be differences
between Array and $wnd.Array...

Reported by t.broyer on 2008-08-21 16:52:41

---

• _Attachment: JsArray_ECMA_methods.patch_

[dankurka]

Reported by scottb+legacy@google.com on 2008-08-21 18:43:06

• Labels added: Type-Enhancement, Category-Other

[dankurka]

Reported by jgw+personal@google.com on 2008-08-21 19:23:07

• Status changed: Accepted
• Labels added: Milestone-Planned

[dankurka]

Whenever I use one of the JsArray classes, I end up putting a bunch of static methods
at the top that call splice, slice, etc.  Also, things I break into JSNI for are
deleting an element, and setting the length.  Can we also get functions for those?

The less JSNI you have to write, the less likely you are to end up with a bug.

Reported by dannydaemonic on 2009-03-15 08:41:39

[dankurka]

Sorry to post again so soon, but I just noticed this issue is a duplicate of issue 233.

Reported by dannydaemonic on 2009-03-15 08:47:30

[dankurka]

I'm going to actually mark the other and a dup and use this one.

Reported by scottb+legacy@google.com on 2009-03-16 15:39:20

[dankurka]

Issue 233 has been merged into this issue.

Reported by scottb+legacy@google.com on 2009-03-16 15:39:45

[dankurka]

Any chance this can get some love for the Q2 fixit (set q2-2009-fixit label for now)?

Reported by sumitchandel+legacy@google.com on 2009-04-29 19:36:54

• Labels added: q2-2009-fixit

[dankurka]

Marvelous idea. I'll have a look.

Reported by jgw+personal@google.com on 2009-04-29 20:08:33

[dankurka]

Reported by sumitchandel+legacy@google.com on 2009-09-16 00:23:01

• Labels added: Fixit
• Labels removed: q2-2009-fixit

[dankurka]

Reported by scottb@google.com on 2010-02-03 17:03:33

[dankurka]

Reported by rjrjr@google.com on 2011-01-13 03:10:17

• Labels added: Type-Feature
• Labels removed: Type-Enhancement

[dankurka]

Just curious, is there something wrong with implementing these?

It seems like a pretty straight forward task.

Reported by patrick.tucker@macefusion.com on 2011-09-13 19:08:48

[dankurka]

Reported by scottb@google.com on 2011-09-13 19:11:24

[dankurka]

Nope. Just another example of low hanging fruit that we just never manage to pick. If
anyone takes Thomas's patch the rest of the way, with tests, I'd be thrilled to review
it.

Reported by rjrjr@google.com on 2011-09-13 20:20:22

• Status changed: PatchesWelcome
• Labels removed: Milestone-Planned, Fixit

[dankurka]

Thanks for the quick response.

Reported by patrick.tucker@macefusion.com on 2011-09-13 20:37:52

[dankurka]

This is up for inclusion in 2.5.1

The one problem is that since JSO methods must be final, adding anything to JsArray
will forever prevent that method from being defined in any subclass.  If people have
already defined them, then this would be a breaking change.

So, my suggestion would be to create a new subclass of JsArray and add them there,
such as JsArrayExt.  If we are willing to accept the breakage (which will be easy to
fix for end users, but harder to fix for libraries intended to work with multiple versions
of GWT), the I am fine with adding them to JsArray.

Reported by jat@jaet.org on 2013-01-12 16:12:57

[dankurka]

I wonder if we shouldn't just close this issue as "fixed by Elemental's elemental.util.ArrayOf*".

Reported by t.broyer on 2013-01-12 18:31:48

[dankurka]

I think that makes sense if JsArray marked deprecated.

Reported by tuckerpmt on 2013-01-13 02:25:32

[dankurka]

I don't think you want to deprecate something in core GWT in favor of something in an
optional library.

Reported by jat@jaet.org on 2013-01-13 04:23:37

[dankurka]

I agree.

It might make sense to move elemental collections to core eventually though, and only
then we can possibly deprecate JsArray*. Not sure it's worth it though.
In any case, I'll split elemental-collections and elemental-json out of Elemental in
the near future.

My point was rather that the JsArrayExt proposed by John already exists (outside core,
granted) as elemental.js.util.JsArrayOf. It's not a subclass of JsArray but it doesn't
really matter as any JavaScriptObject can be cast() to another.
I quickly checked and it seems like JsArrayOf can be made to extend JsArray, as it
seems to share the same implementation for the duplicated methods and has no API conflict.
We could also warn users in the JsArrayOf javadoc that the API can change as new methods
are added from ECMAScript, and users shouldn't extend JsArrayOf.

Reported by t.broyer on 2013-01-13 10:24:07

[dankurka]

I also agree, but if users have to use the optional library for core functionality then
the core should probably get fixed or the optional become core and the lacking implementation
eventually go away.

Reported by tuckerpmt on 2013-01-13 14:10:08