Original author: b...@processing.org (June 07, 2010 01:18:16)

This bug automatically added from:
http://dev.processing.org/bugs/show_bug.cgi?id=1415

Comment from davbol, 2009-12-23 08:49

As of 1.0.9
Now that PVector has become sort of "mainstream", in that for many uses it's no
longer necessary for an end-user to go to an external library for vector/matrix
support, it'd be nice to see it fleshed out a bit more for end-user use.

For example, an obvious ommision is a PVector(PVector source) constructor. Which
currently requires "PVector a = new PVector(); a.set(b);" Similarly, the presence of
set(float []), that implies it'd also be useful to have a PVector(float[] source)
constructor.

The other nicety involves the issue of static methods that return new instances,
versus methods that operate on the original. This setup works fine for discrete
single operations, but becomes cumbersome when stacking operations:

PVector a = new PVector();
PVector b = new PVector(1,2,3);
// c = a + b
PVector c = PVector.add(a,b); // not bad when used like this, but...
println("c = " + c);
// d = (a + (b * 4)) * c
PVector d = PVector.mult(PVector.add(a,PVector.mult(b,4)),c); // getting ugly
println("d = " + d);

Granted, there are alternative ways of wording that code - it's point is just to illustrate
the "wordiness" of creating new instances through stacked operations.

I think I do understand the intent of building it that way, for internal use by core,
reducing memory thrashing of temporary instances, but the end-user might prefer an
alternative syntax.

If the PVector class had a method perhaps named "addNew(PVector v)" (et al) that
created/operated on a new instance, you could instead write:

PVector d = (a.addNew(b).multNew(4)).multNew(c);

That approach is similar to Toxi's vector library (though opposite, where add()
implies a new instance, and addSelf() implies operating internally).

The Java Commons Math Vector3D also defines add() to return a new intance, but
then ALL of their methods return new - there are no "operate internally" methods -
don't really care for that approach either.

And it's not for me to argue about the naming conventions of opSelf vs opNew,
either is fine, but since the existing methods already operate internally, it'd
be "easier" to go with (something like) addNew() and leave add() doing what it
already does.

It's also not easy to just extend PVector as an end-user to implement such ideas
outside of core. It requires a bunch of ugly (and costly) "mangling" code just to gain
this minimal syntactic sugar, f.e.:

class PVectorX extends PVector {
// need to cover some constructors...
PVectorX() { super(); }
PVectorX(float x, float y, float z) { super(x,y,z); }
// this constructor is just to handle "type upgrade" in functions below
// (have to re-wrap the PVector results of static PVector methods into PVectorX's)
PVectorX(PVector v) { this.x=v.x; this.y=v.x; this.z=v.z; }
// then new stuff:
PVectorX addNew(PVector v) { return new PVectorX(PVector.add(this,v)); }
PVectorX multNew(float s) { return new PVectorX(PVector.mult(this,s)); }
PVectorX multNew(PVector v) { return new PVectorX(PVector.mult(this,v)); }
// etc...
}

PVectorX ax = new PVectorX();
PVectorX bx = new PVectorX(1,2,3);
PVectorX cx = ax.addNew(b);
println("cx = " + cx);
PVectorX dx = (ax.addNew(bx).multNew(4)).multNew(cx);
println("dx = " + dx);

(that compiles and runs, btw, but it ain't pretty!)

So it'd be nice to see all variations of input parameters available against all
variations of new/self/staticnew calling conventions on all methods (as applicable).

And, has been mentioned on the forum by others, fe:
http://processing.org/discourse/yabb2/YaBB.pl?num=1259250607
PVector could be made available as argument to many other methods. But that's
almost deserving of a separate topic and its own enh req.

Anyway, just some thoughts/ideas to put on a back burner somewhere.
Cheers

Original issue: http://code.google.com/p/processing/issues/detail?id=218