Processing library classes often are initialized with a reference to the host PApplet, as in

CustomObjectClass custom = new CustomObjectClass(this);

On the other hand, there are often good reasons for having a no-argument initializer for a class.

In the case of graphics objects, one passing the PApplet reference would seem to be useful. The current graphics state can be obtained from the PApplet and used to set the attributes of the custom object.

1.     public void setColors(PApplet parent) {
2.         if (parent.g.fill) {
3.             this.setFillColor(parent.g.fillColor);
4.         }
5.         else {
6.             setNoFill();
7.         }
8.         if (parent.g.stroke) {
9.             this.setStrokeColor(parent.g.strokeColor);
10.             this.setWeight(parent.g.strokeWeight);
11.         }
12.         else {
13.             setNoStroke();
14.         }
15.     }

where "g" is the PGraphics renderer associated with the PApplet. It has other useful information, notatbly the current transformation matrix:

1.     public void setCtm(PApplet parent) {
2.         processing.core.PMatrix2D m = parent.getMatrix(new PMatrix2D());
3.         this.getCtm().setCTM(m.m00, m.m01, m.m10, m.m11, m.m02, m.m12);
4.     }

I had been using a no-argument constructor, basically because it set all defaults to a given state. Users could then call the two methods above to set attributes and have a record of the transformation matrix at the moment when the instance was created (or at any later time, for that matter).

But now I'm inclined to think that initializing a custom graphics object with a PApplet instance may the way to go. At least for users who don't want to write extra code, having an object that behaves like any other Processing graphics object and takes on the current fill and stroke settings is probably a more intuitive way to go.

I wonder if anyone has opinions on this matter?

I'm at the point of releasing a library. That's why this issue has come up. It's easy to go one way or the other, but it would be hard to go back once I release it. Having both a PApplet constructor and a no-argument constructor seems needlessly complicated, and so likely to make the class harder to use.

cheers,

-- Paul