Revisit toString

[jclark]

Given we are doing 2.0, I think we should revisit the design of toString to see if we can come up with something that works better than our current approach.

[jclark]

Need to consider how this relates to #159.

[jclark]

Also related to #135.

[jclark]

New design is as follows.

The spec would define an abstract operation ToString(v, style), where three styles are supported:

• expression style: produces a string that uses a subset of Ballerina expression syntax; guarantees that
  • for a value v that is anydata, the string can be parsed and will produce a value that is == to v
    • if value is acyclic, result will be Ballerina expression
  • for a value v that non anydata, string is distinguishable from value produced for v that is anydata
• informal style: similar to expression style, but
  • avoids some more esoteric Ballerina syntax
  • does not preserve all the distinctions that expression style does
• direct style: converts a value to string in a more direct way, for basic types where this makes sense
  • more direct means converting the value to a string rather than describing the value using a string
    • most importantly, direct style applied to a string leaves string as is
    • xml is represented in XML format
  • falls back to informal style, for basic types where this doesn’t make sense, e.g. for collections
  • for object, uses toString method of object if there is one
    • should probably be required to be isolated

This design is similar to Python:

• Python’s str(x) function corresponds to direct style
• Python’s repr(x) functions corresponds to expression style

Python doesn’t have the third style; this leads to weirdness when applying str(x) to collections, in that the members are output in a way that has an inappropriate level of detail.

The value:toString function would be defined to use direct style.

A new value:toBalString will use expression style. Informal style would probably be available by using arguments to value:toBalString; other options can be added over time (e.g. for pretty printing).

j.toBalString() when j is json is guaranteed not to have newlines; d.toBalString() may have newlines if d contains tables or XML.

These functions should be robust in the presence of cycles. The implementation of toString would have a stack of the structures/objects that are being converted; toString when applied to some object, would first check whether the object is on the stack; if so, then there’s a cycle; otherwise, when it calls toString on members, it does so with itself added to the top of the stack. For now, we have the limitation that there is no mechanism for user-defined toString on objects to deal with cycles.

The following table summarizes the behaviour of the abstract operation ToString(v, style)

Type of v	style
	expression	informal	direct
nil	()	null
true	true
int	2
float	1.0
	float:NaN	NaN
	float:Infinity	Infinity
decimal	1d	1
	1.20d	1.20
string	"xyz"		xyz
xml	xml`<d>t</d>`	`<d>t</d>`	<d>t</d>
array	[X,Y]
	X, Y expression style	X,Y informal style
map	{"x":X,"y":Y}
	X, Y expression style	X,Y informal style
table	table key(k) [R1,R2]	[R1,R2]
	R1,R2 expression style	R1,R2 informal style
error	error D1&D2 (M,C,F1=V1,F2=V2)
	V1, V2 expression style, D is {module}local-name, C expression style	V1, V2 informal style, D is local-name, C informal style
object w/o toString	object D1&D2 U U is an identifier that uniquely identifies the object (based on ===)
object with toString	object S	S
cycle	...[N]	...
	N is 0-based index down path from root object to object where cycle is detected

[lasinicl]

@jclark
Consider applying toString() on an error type value

public type FirstError distinct error;
error cause = error("Account not found", accountID = 123);
FirstError err = FirstError("Reason1", cause, detail = "Failed to get account balance");
string str = err.toString();

Is the expected value of str, the following?

error FirstError (message=Reason1, cause=error error (message=Account not found, detail={"accountID":123}), detail={"detail":"Failed to get account balance"})

For the example given below,

error cause = error("Some issue");
http:FailoverAllEndpointsFailedError err = http:FailoverAllEndpointsFailedError("failoverMessage", failoverErrors = cause);
string str = err.toString();

can this be the expected outcome?

error {ballerina/http}FailoverAllEndpointsFailedError (message=failoverMessage, detail={"failoverErrors":error error (message=Some issue)})

[jclark]

The entry for error in the table isn't quite right: I just edited it.

Note that your syntax is no longer right in Swan Lake. It's

error cause = error("Account not found", accountID = 123);
FirstError err = error FirstError("Reason1", cause, detail = "Failed to get account balance"); // error keyword needed here too

The toString output should look like the constructor:

error FirstError ("Reason1", error("Account not found", accountID=123), detail="Failed to get account balance");

Specifically:

• omit the distinct name if there isn't one
• omit the cause if it's nil

The expression style includes the module name in the distinct type-id.

[mohanvive]

@jclark a quick clarification on map.

Does map contains a space after after the ":" (and before) the value?,

For example,

{"name": "Jane", "age": 25, "spouse": "John", "gender": "female"}

[jclark]

I definitely wouldn't put a space before :. I don't have a strong opinion about after :, but , and : should be treated consistently as regards spacing (for both mappings and lists) So either:

{"name": "Jane", "age": 25, "spouse": "John", "gender": "female"}
[1, 2, 3]

as you wrote, or

{"name":"Jane","age": 25,"spouse": "John","gender":"female"}
[1,2,3]

I slightly prefer with spaces for readability. Which do you prefer?

[mohanvive]

Actually I prefer the second option which you suggested (without spaces), just intuitive.

But shall we make a quick decision on this because there are some dependent changes pending?

[jclark]

I don’t have a strong opinion and I don’t think it matters very much. Do whichever the implementation team prefers and let me know which you decide.

[mohanvive]

Sure James. We are moving forward with the option #2 (without spaces).

[jclark]

OK, I updated the table above accordingly: toString for error also should not add space after string.