I have a reference to a custom class (Point3D)  as a return type in an interface method signature:

Code:

interface I_Shape{
  Point3D[] getVertices();
  void create(float[]x, float[]y);
}
 

I found that I needed to add the static modifier to the custom Point3D class, or I'd get a compile error.  Here's the lovely error:

Quote:


If I convert the interface to a class (and extend instead of implement,) I can lose the static keyword.

However, I'd like to keep the interface and lose the static modifier.

If anyone's interested (some basic oop): I'm doing this to allow a very simple rendering engine to polymorphically handle any geometry passed in. Thus a Toroid or a Helix class could implement my I_Shape interface. The rendering engine would include an object reference of type I_Shape, (rather than either Toroid or Helix.) However, thanks to Java's late method binding, the I_Shape object can call the correct create() method when asked. So for example if a Toroid object is passed in to the engine, and caught by the I_Shape reference, when the I_Shape reference calls create(), the toroid version of the method will be invoked.

JohnG,
Here's some working code. Just comment out the static keyword in Point3D to generate the error. Again, if you modify the sketch, making I_Shape a superclass, you don't need static.

Code:

Cube cube;
Engine engine;
void setup(){
  size(600, 400);
  background(255);
  translate(width/2, height/2);
  cube = new Cube (200, 200, 200);
  engine = new Engine(cube);
  engine.render();
}

// static keyword required
static class Point3D{
  float x, y, z;
  Point3D(float x, float y, float z){
    this.x = x;
    this.y = y;
    this.z = z;
  }
}

class Cube implements I_Shape {
  Point3D[] vertices = new Point3D[24];
  float w, h, d;

  Cube(float w, float h, float d){
    this.w = w;
    this.h = h;
    this.d = d;

    vertices[0] = new Point3D(-w/2,-h/2,d/2);
    vertices[1] = new Point3D(w/2,-h/2,d/2);
    vertices[2] = new Point3D(w/2,h/2,d/2);
    vertices[3] = new Point3D(-w/2,h/2,d/2);
    vertices[4] = new Point3D(-w/2,-h/2,d/2);
    vertices[5] = new Point3D(-w/2,-h/2,-d/2);
    vertices[6] = new Point3D(-w/2,h/2,-d/2);
    vertices[7] = new Point3D(-w/2,h/2,d/2);
    vertices[8] = new Point3D(w/2,-h/2,d/2);
    vertices[9] = new Point3D(w/2,-h/2,-d/2);
    vertices[10] = new Point3D(w/2,h/2,-d/2);
    vertices[11] = new Point3D(w/2,h/2,d/2);
    vertices[12] = new Point3D(-w/2,-h/2,-d/2); 
    vertices[13] = new Point3D(w/2,-h/2,-d/2);
    vertices[14] = new Point3D(w/2,h/2,-d/2);
    vertices[15] = new Point3D(-w/2,h/2,-d/2);
    vertices[16] = new Point3D(-w/2,-h/2,d/2);
    vertices[17] = new Point3D(-w/2,-h/2,-d/2);
    vertices[18] = new Point3D(w/2,-h/2,-d/2);
    vertices[19] = new Point3D(w/2,-h/2,d/2);
    vertices[20] = new Point3D(-w/2,h/2,d/2);
    vertices[21] = new Point3D(-w/2,h/2,-d/2);
    vertices[22] = new Point3D(w/2,h/2,-d/2);
    vertices[23] = new Point3D(w/2,h/2,d/2);
  }

  Point3D[] getVertices(){
    return vertices;
  }

  void create(float[]x, float[]y){
    noFill();
    for (int i=0; i<6; i++){
      beginShape(QUADS);
      for (int j=0; j<4; j++){
        vertex(x[j+4*i], y[j+4*i]);
      }
      endShape();
    }
  }
}

interface I_Shape{
  Point3D[] getVertices();
  void create(float[]x, float[]y);
}

class Engine {
  Point3D[]vertices;
  float[]x;
  float[]y;
  I_Shape shape;

  Engine (I_Shape shape){
    this.shape = shape;
    vertices = shape.getVertices();
    x = new float[vertices.length];
    y = new float[vertices.length];
  }

  void projectionMap(){
    float theta = 45;
    float[]pr = new float[24];
    float d = width/2/tan(radians(theta));
    for (int i=0; i<24; i++){
      pr[i] = d / -(d + vertices[i].z); 
      x[i] =  vertices[i].x * pr[i]; 
      y[i] =  vertices[i].y * pr[i]; 
    }
  }

  void render(){
    projectionMap();
    shape.create(x, y);
  }
}
 

John,
Thanks for your help on this. I believe interfaces may be used within a class (in Java). Here's a Java example that should work:

Code:

public class Outer{
  public Outer(){
    new Inner().speak();
  }

  interface i{
    public void speak();
  }

  class Inner implements i{
    public void speak(){
	System.out.println("Greetings from the inner");
    }
  }

  public static void main(String[]a){
    new Outer();
  }
}

 

I did originally set up the classes as separate tabs, but used the default pde suffix. I'm happy to know the java suffix worked, but similarly to using the static keyword, it seems more like a hack. I realize this may be a pretty advanced issue for many users, but polymorphism is so fundamental to Java, I wonder if this needs to be looked at more closely. (Although, I'm still hoping I'm missing something more obvious here.) I do appreciate you taking the time to think/work on this.

Thanks Ben.
However just to be clear, (and probably damn annoying,) the static keyword is not required in Java, even stacking everything within a  single class; but it is in Processing. It's really the inconsistency that I was confused by.

For example, the code below compiles/runs fine in Java without the static keyword, which is required in Processing. (I'll really shut up now.)

Code:

public class Outer{
  public Outer(){
    Inner1 inner1 = new Inner1();
    Inner2 inner2 = new Inner2();
    new Speaker(inner1);
    new Speaker(inner2);
  }

  interface I{
    public void speak();
    public Point3D getPoint();
  }

  class Inner1 implements I{
    public void speak(){
      System.out.println(
      "Greetings from inner1");
    }
    public Point3D getPoint(){
      return new Point3D(1, 2, 3);
    }
  }

  class Inner2 implements I{
    public void speak(){
      System.out.println(
      "Greetings from inner2");
    }
    public Point3D getPoint(){
      return new Point3D(4, 5, 6);
    }
  }

  class Speaker {
    public Speaker(I iType){
      iType.speak();
      System.out.println("x = " + 
        iType.getPoint().x);
    }
  }

  public static void main(String[]a){
    new Outer();
  }

  class Point3D{ 
    float x, y, z; 
    Point3D(float x, float y, float z){ 
      this.x = x; 
      this.y = y; 
      this.z = z; 
    } 
  } 
}
 

I'm confused. Not that I can't do what I want, but I'm not sure what the best practice is.

Do you guys consider stuff like interfaces and abstract classes to be part of the Processing language proper, or have I just started talking Java in my Processing code if I do this? Or don't you care? (Which imho is a valid position, too)

I think this is a complet(-ish) list of what I'm thinking of:

final
static
abstract
interface - implements

try - catch (i.e. Exception handling)

And then of course using Java classes - but I'm thinking of syntax here.

The question is: as a matter of style - is it neater to avoid using Java syntax (say, stuff that is not listed in the Extended Processing API) in .pde files and only use it in .java files? I mean, is there a point in trying to keep Processing "clean" or should we just go ahead and mix Java and Processing full out?

Another option is of course to accept these things as integral parts of Processing as well, but then maybe they should be listed in the API docs.

Obviously you can just do whatever works for you, but I'm thinking of style, and maybe of ways of easing the way into Processing for people who are not already Java-fluent. If I were a coding noob trying to learn Processing I would hate to look at other people's code and find that they're using syntax that is not listed in the docs...

/Fredrik Bridell


Food for thought:
"A pidgin, or contact language, is the name given to any language created, usually spontaneously, out of a mixture of other languages as a means of communication between speakers of different tongues." - from "Pidgin" entry in Wikipedia

Yeah, I know what they mean. My question was whether or not it's a good idea to use them in Processing code. (And yes, public and private should go on top of the list)

I think you have a good point there - for simple stuff or in teaching basic coding you can just avoid using most of this stuff altogether. If you just want to make something move on a screen there's little point in worrying about proper encapsulation and polymorphism using interfaces and so on.

My main point is that I want to avoid posting code that claims to be Processing code but contains syntax elements that can't be found in the Processing docs (http://processing.org/reference/).

My working solution is putting such code in a .java tab and pass on the PApplet instance. That keeps the Processing code clean and shows (rather than hides) the way it integrates with Java. And it may save you from "the static bug"...

bridell wrote on Dec 29^th, 2006, 11:04am:

i guess we've never really drawn a line on it. since it's in java, it's still available within p5, just with a few caveats (and bugs apparently, as in the case of what ira also found). in the last six months or so we've seen a real uptick in people mixing java and p5 code, or more advanced java developers using p5. at some point i'll need to better outline how they relate, i suppose.

for the time being, i'd say mix as you wish. the intent of the basic reference is to get at nearly all the things that our target audience will want to do, and when they outgrow that, they start learning about more java code, and can mix that in. we don't say "if it's not in the basic reference, that's not p5", though we might be less inclined to fix things that involve weird interactions with java language features.

as for private/static/final etc.. these are of minimal usefulness for the scope of projects created with p5 (generally 1-5 classes, most of them inner), except that:

- private and final can be useful when applied to methods, because smart java compilers can inline these methods for greater speed

- static is less useful because you can't have static variables in an inner class, and by default, all the other tabs are inner classes. the way to deal with this is simply placing the 'static' variable (it needn't be static at that point) outside the actual class definition inside the tab.

as for things like private class/static class/etc.. i find them to be unnecessary abominations that muddy the spec. similar goes for much of the weird syntax things added in 1.5, but i'm coming around on some of it i suppose.

does that help clear as mud, i s'pose.

I tried st33d's code and he(?) is right - his code IS faster. I ran 100 iterations and tried it with a Vector and an ArrayList (which have the same List interface). I used Java 1.5.0 straight up, not using Processing, not using java generics - aka "the weird syntax things" .

Results:
Vector: java 28257, st33d 22239 - st33d wins at 79%
ArrayList: java 28046, st33d 2528 - st33d wins at 9% (!)

A look at the Java source code shows that the difference is that the Java system libraries use .equals(), not ==. If you try the code above but using equals() it's actually a little slower than the system implementation.

Oh - a comment. If you really want to speed things up, the trick is really not optimizing the linear search you're doing, but to pick another type of data storage, something that's already sorted - some sort of tree, perhaps? That all depends on what you're doing, and what sort of data you're dealing with.



/Bridell