[2.0] Add array, vector overloads to `createVector()` for consistency

[GregStanton]

[2.0] Add array, vector overloads to createVector() for consistency

Currently, vector operations often allow vectors to be specified in three ways: separate number arguments, a number array, or a vector instance. For example, add(), sub(), mult(), div(), and rem() all work this way. Ideally, we would always allow users to specify vectors in the same ways, so they don't need to guess which vector features accept which overloads. We already do this with color features like fill() and stroke(), which have a consistent set of overloads for specifying colors.

If adding array and vector overloads to createVector() sounds good, then we might also consider deprecating the copy() method, as it would no longer be needed: v.copy() could be replaced by createVector(v).

Tasks:

• Reach consensus on adding overloads
• Implement and document

[kunal-595]

Hii @GregStanton , i would love to work on this issue as my first contribution to the organization , could you please assign it to me ?

[ayushman1210]

hi @GregStanton could you please assign me this issue ?

[lokesh-singhal]

Hey @GregStanton,
I’d like to work on this issue.
We can use x instanceof p5.Vector to handle vector inputs and Array.isArray(x) for array inputs inside createVector().
Could you please assign this issue to me so I can implement it?

[davepagurek]

+1 for allowing more overloads in createVector. I think .copy() maybe has enough of a separate use that it doesn't need to be deprecated though. Because vectors can't use regular math operations and rely on methods, users make extensive use of method chaining. A .copy() fits well into the feel of this, and having to wrap something in createVector(...) breaks that flow. Also using createVector(...) to create a copy, while it makes sense that it should work, feels like a slight indirection from an initial intent of "I want to create a copy of this object." Those are all fairly minor points, but between that and the heavy use of .copy in the wild, I'm not sure API simplification alone is strong enough to justify deprecation.

[GregStanton]

I think .copy() maybe has enough of a separate use that it doesn't need to be deprecated though.

Excellent point, thanks Dave! I think that makes sense.