Overloading for PVector

ailwon

Given the strength and utility of PVector, it is perhaps surprising that common methods have not been overloaded to accommodate encapsulated PVector (so that PVector fields do not need to be continually boxed and, particularly, unboxed). We have created a small set of such overloads "as necessary" but it seems that such an extensions to the base processing PApplet would be generally useful.

KevinWorkman

I'm not sure what your question is?

Can you provide us an example of one of these methods and a scenario where it comes in handy?

Chrisir

have you made a lib?

could you post the link?

thank you!

;-)

GoToLoop

• I also believe that since Processing has a container which starts w/ an uppercase P such as PVector, it should integrate it more across its API! 8-|
• How about an overloaded line(PVector start, PVector end)?
• And rect(PVector coord, PVector diameter).
• Or even rect(Rectangle r) would be even cooler! \m/
• But only a miracle to convince developers to do anything beyond what they've already "set in stone" eons ago! [-O<
• Believe me, I've tried. And it wasn't a good experience! :-<

KevinWorkman

Processing is open-source. If you really want those functions, you can add them.

I would argue that they don't belong in the Processing core because they don't really add much functionality that you can't add yourself in 3 lines or so. And the PApplet class is already long enough!

GoToLoop

• Open source w/ iron claw guard dogs.
• Overloaded methods should be advanced further, b/c they reduce the clutter from our sketches.
• And who cares if it makes the source code a little fatter in order to add such niceties? >:)

KevinWorkman

Open source w/ iron claw guard dogs.

You can still build from the source and add whatever methods you want. You could even fork the project and put your own version up on GitHub. If that sounds like a lot of work, then you're starting to understand why they don't accept every single code addition.

Overloaded methods should be advanced further, b/c they reduce the clutter from our sketches.

You're "reducing the clutter" by 3 whole lines.

And who cares if it makes the source code a little fatter in order to add such niceties?

The people working on the code.

quark

Actually we are not talking about overloading the PVector class rather PApplet and PGrahics (plus its subclasses).

There must be hundreds of methods that use the screen coordinates which could be overloaded to accept PVector parameters. That's a shed load of code to write and maintain.

GoToLoop

There must be hundreds of methods that use the screen coordinates...

I doubt it is that much by looking at Processing's API reference:
https://processing.org/reference/

That's a shed load of code to write and maintain.

Those are merely unboxing code. Like this 1 for example:

void line(PVector start, PVector end) {
  line(start.x, start.y, end.x, end.y);
}

They could even implement some helper class to place those overloaded functions there. *-:)

As I highlighted, PVector is a Processing's invention. And it surely feels very isolated right now.
Integrating PVector across Processing's API have lotsa good effects:
Make the "language" easier, uncluttered and more streamlined! :-bd

GoToLoop

// forum.processing.org/two/discussion/10751/overloading-for-pvector
// 2015-May-11

void line(PVector start, PVector end) {
  line(start.x, start.y, end.x, end.y);
}

final PVector p1 = new PVector(), p2 = new PVector();

void setup() {
  size(400, 400, JAVA2D);

  smooth(4);
  noLoop();
  noCursor();
  stroke(#FFFF00);
  strokeWeight(4);

  p1.set(width>>1, height>>1);
}

void draw() {
  background(#0000FF);
  line(p1, p2);
}

void mouseMoved() {
  p2.set(mouseX, mouseY);
  redraw();
}