toString should implicitly always proxy to jsii

[eladb]

In all languages we should always proxy toString calls to JavaScript so the behavior is consistent with how JS works in that respect, regardless if toString is explicitly defined or not.

[eladb]

I am thinking that the robust way to implement this is to implicitly add a toString method to all jsii classes (at the manifest level). This will streamline the behavior downstream without needing to special-base. @rix0rrr what do you think?

[rix0rrr]

I don't think we can do it without cooperation of the language generator. It depends on the language how the downstream methods need to be named:

Language	TypeScript name	Language name	Remarks
Java	toString()	toString()	works out
.NET	toString()	ToString()	works out
Python	toString()	__str__()	ooops!

[eladb]

We already have the renames covered in the conformance tests, just not the implicitness

[rix0rrr]

I don't know what that means.

But the knowledge that toString() in JavaScript maps onto __str__() in Python (instead of to_string() which is what the usual rules would map it to) needs to live somewhere, and that means toString() is special.

We can tackle that in three ways, as far as I can see.

---

1. All classes have an explicit toString() method in the JSII model, and the method name toString is special

JSII generators are supposed to know that toString() has special semantics, and every language has to do the mapping between toString() and their own representation of that function.

It coincidentally so happens that the Java and .NET generators already do the right thing (by accident) so we don't have to change them => win!

Only jsii and the Python code generator need to do something here.

2. All classes have an explicit "stringifier" method

Similar to 1., except we don't hardcode the name toString(); instead, we mark a method stringifier: true, similar to how we have initializer: true, to indicate this is a method that is outside the normal rules of methods calls.

The spec, jsii and all generators need to change to support this new method type.

3. All classes have an implicit stringifier method by definition

By virtue of being a JSII class, it can be assumed that the class can be stringified, by calling a toString() method. Generates generate the right code that maps onto their local concept of automatic stringification.

All generators need to change, but the spec and jsii can stay the same.

---

My preference would be nr 3, but I can see how we might want to avoid the cost of updating the C# generator, in which case I would say nr 1. I don't think option 2 is worth the code churn.

[RomainMuller]

I like 3 in @rix0rrr's options as well.

[github-actions]

This issue has not received any attention in 2 years. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.