[2.0] Stabilize the `toString()` method of `p5.Vector`

[GregStanton]

[2.0] Stabilize the toString() method of p5.Vector

In 1.x, the code createVector(2, 3).toString() would return the string 'p5.Vector Object : [2, 3, 0]', whereas in 2.0.5, it returns '[2, 3]'. This is intentional, since 2.x is intended to support separate 1D, 2D, 3D, 4D, ... vectors, rather than representing all vectors as 3D vectors. However, we need to determine whether the substring 'p5.Vector Object : ' should be added back in.

Ideally, the behavior of the toString() methods on p5.Vector and p5.Color would be consistent. For example, in 2.x, color('red').toString() returns 'rgb(100% 0% 0%)'. Arguably, p5.Vector Object : is analogous to rgb, as it specifies not just the components, but also how they are to be interpreted. However, it may also be true that this extra text makes it harder to use the string as a serialized version of a vector. Maybe? I haven't looked into this, but @limzykenneth commented on this use of the vector version of toString(), in relation to storeItem().

Tasks:

• Reach consensus on the desired behavior
• Implement the behavior (or leave it as is)
• Update documentation
• Update compatibility README

[Ayaan005-sudo]

Hey! I’ve been exploring this issue and I understand the change from 3D default vectors to flexible dimensionality in 2.x. I think keeping the "p5.Vector Object : " prefix helps clarify the type, similar to how color().toString() returns "rgb(...)". But I also see the concern about serialization — prefix makes it harder to parse the string directly with JSON.parse() or reuse it programmatically. Happy to implement whichever direction the community prefers!

[Ayaan005-sudo]

Just adding a quick note — even with the "p5.Vector Object : " prefix, it's possible to parse the string by splitting and trimming before using JSON.parse(). So it's not a blocker, but removing the prefix would make serialization smoother. Thanks!