This gives my framework errors:

Illegal argument type com.google.gson.JsonObject, expecting java.math.BigDecimal or java.lang.String

On the plus sign I noticed an impressive performance improvement.

Example, this gives an error with the PR but didn't before:

[h: json = json.set("{}", "property", "value")] 
[frame("test", "value=" + json):{}]

A workaround is to replace json with string(json).

@Merudo checking your test on illegal argument

confirmed - since json arrays are not flattened all the time the addition doesn't handle the + well, I'll add a test-case. You're workaround to convert to string is right but I think we can make this backwards compatible

[h: "test" + json.set("{}", "property", "value")]

It's because the parser was automatically converting json arrays and objects in variables to strings, and it isn't anymore.

Example:

[h: jobj = json.set("{}", "property", "value")] 
[r: "Json Object: " + jobj] 

This returns Json Object: {"property":"value"} in 1.7 but gives an error in develop.

Which may be fine, really. The workaround is just to add string() around the variable.

If we keep this change, we should make it clear to users, though.

confirmed - since json arrays are not flattened all the time the addition doesn't handle the + well, I'll add a test-case. You're workaround to convert to string is right but I think we can make this backwards compatible

[h: "test" + json.set("{}", "property", "value")]

Yep, jsons should be automatically converted to strings when used with the + operator, otherwise the operation is not meaningful.

This would preserve backward compatibility while opening up other ways to deal with json elements.

Yeah, it does makes sense to require conversion, otherwise most of functions don't make sense.

Not good for those macro scripts using any of those functions below at this point

    net.rptools.maptool.client.functions 
        InputFunction  
        ReturnFunction  
        StrListFunctions  
        StrPropFunctions 
    net.rptools.parser.function 
        AbstractComparisonFunction 
        AbstractLogicalOperatorFunction 
        AbstractNumberFunction 
    net.rptools.parser.function.impl 
        Addition 
        Equals  (equals could do an equals on a json array, requires another parser update though)
        Eval 
        Mean 
        Median 
        NotEquals  (same, is possible to do on json array)
        StrEquals 
        StrNotEquals 

@nmeier should we expect a fix for this or should it be reverted?

My dev environment (Linux Mint 19.3, JDK 14) is failing a unit test starting at this merge commit - MapToolLineParserTest.testMacros():

expected line #1:`expanded roll sh[...]` doesn't match ==> expected: <
expanded roll shows ...if\(1 == 1, 1, 0\) = 1.
> but was: <
expanded roll shows ���if(1 == 1, 1, 0) = 1�1�
>

I think we should leave as is - making these operations backwards comp we can rule out for operations between string and the (non flattened) json objects. I think one can argue about (not)equals but the code is just full of assumptions about string/bigdecimal so I'm not sure it's worth it.

@selquest looking at that test-case, it works here on Windows. The special characters that maptool adds for expanded Rolls might be different in your setup.

I think it would make sense for the Addition functions to automatically convert json elements into strings. This should be a straightforward modification to the parser that would preserve backward compatibility.

added a PR that makes those operations (+, ==, etc.) work backwards so this works fine again

[r: "test" + json.set("{}", "property", "value")]

RPTools/parser#42

Parser bumped to 1.8.1.