"What if you were working on a team, and somebody used the wrong variable from your Ball class?"

Well, you either consider your teammate a competitor or a brain-dead incompetent! 

Nested classes and their top-class share everything among them.
Access keywords like private, protected and such don't affect that sharing at all.
They only affect foreign classes accessing them.

What you can do is creating a separate tab for a class w/ the following rules:

1. Gotta be the same name as the class put in there.
2. Gotta have suffix .java in that name.
   

That tab is now considered a regular Java class file. And access restriction works there.

However, you gotta get a PApplet reference from the main sketch
in order for that Java class to communicate w/ the Processing API.

You can promote an inner class to a top-level class by making with the static keyword change the ball class to

static class Ball {                                           

You can promote an inner class to a top-level class by making with the static keyword...

It just makes a nested inner class become a static nested class.

Even though it behaves somewhat as a top-class when accessed from a foreign class,
it's still a nested class from the main sketch top-class.

And worse, it can't use most of Processing's API, since most are non-static!

But since a .java tab gonna need a PApplet reference anyways,
I guess the same can be applied to static nested classes.

Gotta test it yet. 

My end goal is to create a series of tutorials that go from the very basics using Processing, then on to Java and more complicated stuff like libGDX. I'm trying to introduce the basics of creating objects and presently using access modifiers, that way when they get to Hello World in Java they understand exactly what's going on without any hand-waving on my part. So I'm trying to stay away from writing real Java code just yet. I was hoping there was a way to use private in pure Processing (was hoping that putting Ball into its own tab without the .java extension would help, no luck), but it looks like that might just not be doable.

Just teach them how to make classes into separate tabs w/ .java.
And how to get a PApplet reference at its constructor. And how to use that reference.

Anyways, in a real Java environment, we gotta put each class in a separate file.
They have to learn that sooner or later! 

That's an interesting option. I'll try to think of a way to do that without going over beginner's heads, which is a challenge in itself. Thanks for the idea.

And worse, it can't use most of Processing's API, since most are non-static!

that goes for ANY top-level class,  but you have already given the solution to that.

However, you gotta get a PApplet reference from the main sketch
in order for that Java class to communicate w/ the Processing API.

- the only real difference would be instantiating and using an object of this static inner class in other top level classes.

Processing used Java because it could be run cross platform, it was designed so that programmers had an easy API to produce graphics and avoid OOP.

Many Processing users progress to OOP by creating simple classes of their own (e.g. Ball) or by using Processing's classes (e.g. PVector). Generally these are created as inner classes because it enables virtually unrestricted access to variables in the sketch and the attributes (fields) of the inner class.

This gives a very skewed view of OOP, in that most OO principles are simply ignored for a simpler implementation. When the programmer progresses to larger and more complex programs and moves to a more sophisticated IDE like Eclipse or NetBeans and perhaps get involved in team projects they still have a steep learning curve.

quarks, I've tried your static class approach but it didn't work! 
The private fields from the static nested class can be completely accessed just like a regular inner class! 

"NestedBall.pde":

---

NestedBall ball;

void setup() {
  size(500, 500);
  ellipseMode(CENTER);

  ball = new NestedBall(this);

  println(ball.p);  // private PApplet p can be accessed
}

void draw() {
  background(0);
  ball.script();
}

void mousePressed() { 
  // was hoping for a compiler error here:
  ball.x = mouseX;
  ball.y = mouseY;
}

static class NestedBall {
  private int x = 250, y = 250;

  final int tx, ty;

  final static int DIM = 25;

  private final PApplet p;

  NestedBall(PApplet pa) {
    p = pa;
    tx = pa.width  >> 1;
    ty = pa.height >> 1;
  }

  void update() {
    x += x == tx? 0 : x < tx? 1 : -1;
    y += y == ty? 0 : y < ty? 1 : -1;
  }

  void display() {
    p.ellipse(x, y, 25, 25);
  }

  void script() {
    update();
    display();
  }
}

---

Only in a separate .java tab those access restriction keywords work as intended:

"MainSketch.pde":

---

JavaBall ball;

void setup() {
  size(500, 500);
  ellipseMode(CENTER);

  ball = new JavaBall(this);
}

void draw() {
  background(0);
  ball.script();
}

void mousePressed() { 
  //ball.x = mouseX; // The field JavaBall.x is not visible
  //ball.y = mouseY;

  ball.setXY(mouseX, mouseY); // must use an accessor now
}

---

"JavaBall.java":

---

import processing.core.*;

class JavaBall {
  private int x = 250, y = 250;

  final int tx, ty;

  final static int DIM = 25;

  private final PApplet p;

  JavaBall(PApplet pa) {
    p = pa;
    tx = pa.width  >> 1;
    ty = pa.height >> 1;
  }

  void update() {
    x += x == tx? 0 : x < tx? 1 : -1;
    y += y == ty? 0 : y < ty? 1 : -1;
  }

  void display() {
    p.ellipse(x, y, DIM, DIM);
  }

  void script() {
    update();
    display();
  }

  void setXY(int xx, int yy) {
    x = xx;
    y = yy;
  }

  int getX() {
    return x;
  }

  int getY() {
    return y;
  }
}

---

I've tried your static class approach but it didn't work!

Well done on picking that up - I never checked myself.

In OOP inner classes serve a very specific purpose so I never get to use them much. If I was developing an application with a Ball class I would NEVER consider implementing it as an inner class so I never thought to check.

Of course the nature of Processing encourages beginners to use inner classes. Students of OOP would learn to create top-level classes first and design them based on the principles of OO, only being introduced inner classes when creating custom event handlers.

BTW there maybe another good reason to avoid inner classes because I think there is a bug in Processing's pre=processor - see this topic

@GoTo,

BTW, there maybe another good reason to avoid inner classes because I think there is a bug in Processing's pre-processor.

Keyword color can be either a function or a syntax sugar for the primitive data-type int.
It is a pre-compiler bug indeed. But it only affects the color() function when used through a PApplet reference.
To circumvent that, just use web color or hexadecimal color formats. It's faster this way anyways! 

The main purpose of a static nested class is for a foreign class to avoid the extra step
of instantiating the top-class to reach any of its inner class(es).

As I've demonstrated above, a static nested class is as useless as a regular inner class for information hiding. 

The main purpose of a static nested class is for a foreign class to avoid the extra step
of instantiating the top-class to reach any of its inner class(es).

That might be the case in Processing but its not the case in OOP

BTW GoToLoop thanks for the heads-up on the pre-processor and color problem.

However I still use a lot static inner classes (in pure java) to encapsulate inside of the class objects which are only for the usage of this class. Because if you declare it as separate class it will always be available for the whole package.

However I still use a lot static inner classes (in pure java) to encapsulate inside of the class objects which are only for the usage of this class.

This makes sense.

Because if you declare it as separate class it will always be available for the whole package.

I don't see that as a problem unless you are using the default (un-named package). All of the contributed libraries are created in named packages so any sketch or Java application using them would not have access to package scope classes, methods or attributes.

There are other situations were inner classes can be used very effectively, but normally rather than instantiate the inner class directly with
new OuterClass.InnerClass();

it is more common to use a static method (or possible an instance method) of the enclosing class to create and return an object of the correct inner class.

That might be the case in Processing but its not the case in OOP.

I really meant outside Processing. Of course, in relation to the Java language itself.
Not for some OOP philosophy.

As I've mentioned before, Processing really "hates" anything static.
B/c most of its API can't be directly accessed by static nested classes or methods.

Besides, a Processing app wasn't meant to be instantiated more than once.
So, whether a field or a method is static or not in a sketch is irrelevant.

Pay attention that I was talking about static nested classes.
Don't confuse that w/ inner classes, which aren't static.
Even though both are nested classes, only the non-static version is called inner.

What I really meant was:

The main reason some1 would choose a static nested class over a non-static nested class (inner)
is for a foreign class to be able to access that w/o the need of instantiating its top-class.

I said that b/c a static nested class failed miserably at replacing a real top class
for the purpose of information hiding. So what else a static nested class is for? 

If there is a more important reason than easing access from a foreign class, I'm all ears! 

Anyways, I've included a static nested class called JavaSquare inside top-class JavaBall.

As you'll see, I was able to instantiate JavaSquare w/o creating
an instance of JavaBall from within main sketch.

It means the foreign sketch class was able to ignore instantiating
the top class JavaBall to access JavaSquare.

Check it out:

"MainSketch".pde:

---

JavaBall.JavaSquare square;
JavaBall ball;

boolean SquareOrCircle = true;

void setup() {
  size(500, 500);
  frameRate(60);

  ellipseMode(CENTER);
  rectMode(CENTER);

  fill(0200);
  stroke(0100);
  strokeWeight(3);

  square = new JavaBall.JavaSquare(this);
  ball   = new JavaBall(this);
}

void draw() {
  background(-1);

  square.update();
  ball.update();

  if (SquareOrCircle)  square.display();
  else                 ball.display();
}

void mousePressed() { 
  //square.x = mouseX; // The field JavaBall.JavaSquare.x is not visible
  //square.y = mouseY;

  if (mouseButton == RIGHT)
    SquareOrCircle = !SquareOrCircle;

  else if (mouseButton == CENTER)
    fill( (color) random(#000000) );

  else {
    square.setXY(mouseX, mouseY); // must use an accessor now
    ball.setXY(mouseX, mouseY);   // must use an accessor now
  }
}

---

"JavaBall.java":

---

import processing.core.*;

// Top Class:

class JavaBall {
  final static int DIM = 40, SPD = 3;

  private static PApplet p;

  private int x, y;
  final int tx, ty;

  JavaBall(PApplet pa) {
    p = pa;
    x = tx = pa.width  >> 1;
    y = ty = pa.height >> 1;
  }

  void update() {
    x += x == tx? 0 : x < tx? SPD : -SPD;
    y += y == ty? 0 : y < ty? SPD : -SPD;
  }

  void display() {
    p.ellipse(x, y, DIM, DIM);
  }

  void script() {
    update();
    display();
  }

  void setXY(int xx, int yy) {
    x = xx;
    y = yy;
  }

  int getX() {
    return x;
  }

  int getY() {
    return y;
  }

  // Static Nested Class:

  static class JavaSquare {
    private int x, y;
    final int tx, ty;

    JavaSquare(PApplet pa) {
      p = pa;
      x = tx = pa.width  >> 1;
      y = ty = pa.height >> 1;
    }

    void update() {
      x += x == tx? 0 : x < tx? SPD : -SPD;
      y += y == ty? 0 : y < ty? SPD : -SPD;
    }

    void display() {
      p.rect(x, y, DIM, DIM);
    }

    void script() {
      update();
      display();
    }

    void setXY(int xx, int yy) {
      x = xx;
      y = yy;
    }

    int getX() {
      return x;
    }

    int getY() {
      return y;
    }
  }
}

---

 This gives a very skewed view of OOP, in that most OO principles are simply ignored for a simpler implementation. When the programmer progresses to larger and more complex programs and moves to a more sophisticated IDE like Eclipse or NetBeans and perhaps get involved in team projects they still have a steep learning curve.

This is exactly the learning curve I'm trying to diminish. I started writing a Hello World in Java, and realized that half of the keywords were completely new, so I've been going back and trying to introduce the concepts in Processing. That's when I hit this wall.

Well done on picking that up - I never checked myself.

hey that's an amzing discovery (about inner classes, static or non-static) sharing "private" scope with the enclosing class...  never knew about it... just tried and it also applies to pure-java.  

Inner classes in Java share their variables with the outer class (and vice versa). The problem is that *every* class in Processing is an inner class.

The main purpose of a static nested class is for a foreign class to avoid the extra step
of instantiating the top-class to reach any of its inner class(es).

This is probably just an oversimplification, but as stated, I don't really agree with this statement.

However I still use a lot static inner classes (in pure java) to encapsulate inside of the class objects which are only for the usage of this class.

Why static? Sounds like a job for a non-static inner class, or even a top-level class. But now we're splitting hairs and getting away from my real goal, so I digress.

Anyway, I'm still curious about my actual goal of trying to teach the private keyword in a purely Processing environment. If nothing else I'll probably go the route of adding a .java tab and introducing the concepts that way, but I'd still love a purely Processing alternative.

However I still use a lot static inner classes (in pure java) to encapsulate inside of the class objects which are only for the usage of this class.

In Java's terminology, it's wrong to say static inner class.
An inner class, even though it's nested as its static counterpart, is always non-static.

That is, once an inner class is declared static, it stops being "inner",
and now resembles a top-class due to its easier direct access from foreign classes.
Although it's no different from its inner form in relation to information hiding.

That's the missing info why I'm being misunderstood. 

And I hope it's now more evident to understand why I said a static inner class' main purpose
is to facilitate its direct access w/o any instantiation of its top class!

I wasn't talking about regular inner classes and its useful purpose of internal encapsulation at all.

If nothing else I'll probably go the route of adding a .java tab and introducing the concepts that way, but I'd still love a purely Processing alternative.

If you wanna teach information hiding, as you have noticed, you'll really need a real top class.
And in the context of Processing's IDE, you'll need a tab w/ .java suffix I'm afraid. 

Although I think information hiding is more adequate for business apps rather than graphics sketches. 

Anyway, I'm still curious about my actual goal of trying to teach the private keyword in a purely Processing environment. If nothing else I'll probably go the route of adding a .java tab and introducing the concepts that way, but I'd still love a purely Processing alternative.

This is impossible because the whole ethos of Processes is simplicity which means avoiding object orientation.



I agree with GoToLoop's last post, but I would make a small change to the wording.

If you want to teach object orientated programming, start with top-level classes by using a seperate .java tab for each class.

This would allow you to teach the difference between public, private and protected access specifiers and all the benefits of avoiding public attributes / fields (not just information hiding). It would also help when teaching more advanced topics like inheritance and polymorphism.

I also agree that in most Processing sketches the programmer could benefit with basic knowledge about classes and objects so as to be able to create and use inner classes. If the programmer wants to create larger more complex sketches or want to start creating libraries and tools, a much more extensive knowledge of object orientated methodology would be beneficial. A good basic knowledge of designing and implementing top-level classes would be a step in thr right direction.