toString() for array arguments in GREL returns a memory address. Consider giving a more intuitive representation.

In GREL, toString( [ 3 ,4]), will return something like: [Ljava.lang.Object;@79738ce6. It would be helpful to provide a more intuitive and natural representation, such as: [ 3, 4 ]. Something like java.util.Arrays.deepToString might give a better meaning when running toString on an array in GREL.

Thoughts?

Some Additional Information: You will also notice that the expression preview of the array [ 3 ,4] already shows a more natural representation: [ 3, 4 ]. Because arrays are not storable however, attempting to run this transformation leads to the error: Object[] value not storable. This is conflicting behavior. The preview shows a valid transformation, yet the execution of the transformation results in an error. See issue #1088 for more information on storing and displaying arrays in GREL.

[ostephens]

@NavpreetKR @darecoder1999 to reproduce the error in the application start OpenRefine, open a project and in a GREL transformation window (on any column choose dropdown menu and Edit cells -> Transform) and then type the text:

([3,4]).toString()

That will reproduce the error.

In terms of tackling this issue I recommend starting with a test - we have tests for various to/from string conversions in main/tests/server/src/com/google/refine/tests/expr/functions/strings/ToFromConversionTests.java

If you can write some tests to show the correct behaviour then you should be able to see this fail by running the tests. Then start tackling implementing the appropriate behaviour.

Definitely review some of the discussion in #1088 as @thadguidry suggested - I think that will be helpful

[thadguidry]

@darecoder1999 Context: Most of our users are not programmers. To them, an array is just a “list with separators”. They don’t care about Objects, but the fields and data contained within any Object. To get to the data, the GREL convention has historically been toString(). In GREL, we try to provide powerful functions that can be combined together. We typically have tried to avoid overloading functions with too many arguments, and instead create new functions, as necessary. In this case, it could be like that, where rather than overloading or changing toString(), we could certainly introduce a new high level function like say unwrap() or we could go and choose to make it very specific, like arrayToString().

Our philosophy for GREL has been…the best choice for our users will be one that fits with the current workflow style of GREL’s existing syntax of functions, and that allows users to extract the data they want, and allow them to format it easily, if necessary inside GREL, by combining with other functions for formatting. (I just realized we don’t have a good subsection on our wiki for GREL’s originating ideas from David Huynh, the original designer!)

In my example and proof of concept code in that #1088 comment I chose to overload and change the toString() function and I tested it, but not everyone did.

I’d suggest reading through that Google Groups mailing list thread mentioned just above that comment and following along my discussion with @ostephens in the thread at that time.

As well as reading the changes on the toString() function over time on our wiki: https://github.com/OpenRefine/OpenRefine/wiki/GREL-String-Functions#tostringvalue

UPDATE: You’ll notice in that wiki page, we say that toString will work with any value type, but that’s not 100% true, as in this issue, it doesn’t work well with Array types, and we don’t currently store Array types in cells yet. 😃 My example code fixed this issue in particular, but not tested thoroughly. You are welcome to copy it and provide a PR.