Public Class vs Private Class

Processing Beginners
1

This is basically a concept question.

And I have read the reference entries on the processing site, as well as on stackoverflow site.

Is public vs private class a similar concept as with variable scope – global vs local – primitive datatypes?

Is this something that someone coming from a java background would implement in their code as a default subtlety as opposed to someone with no prior coding experience?

2

Members declared w/ the keyword private can’t be accessed outside the class they belong to.
However, there are some caveats:

  1. Java reflection operation allows us to access any member regardless its permission/visibility.
  2. If a class happens to be a nested member inside another, nothing is actually private for both the nested and its outer class.
1 Like
3

Thank you @GoToLoop.
I guess I am trying to understand it as a broader concept. Is it to be thought of in the same way as how global and local variables operate?

4
  • Conceptually, Java doesn’t have actual global variables.
  • Classes & interfaces’ fields act as global variables.
  • In normal circumstances, local variables & parameters cease to exist when their function returns.
5

So I am understanding you to say the concept of scope is fundamentally different in Java vs processing… Just want to confirm.

And that not to conceptually link variable scope with public/private classes.

6

The idea of global and local variables are associated with the procedural programming paradigm. The idea was to be able to create useful functions that could be used in different programs without worrying about variable name clashes.

public, private and protected are access modifiers used in the object orientated paradigm and control the visibility of classes, methods and attributes.

So although ther are some basic similarity in purpose i.e. control access to variables, they are very different in how they work.

7

What Processing calls global variables will become fields of the subclass PApplet when we hit PDE’s run button.

8

Thank you @GoToLoop and @quark for your explanations! That helps. :slight_smile:

9

Scope allows us to use for(int i=0... in many places in our program without those all referencing the same variable. Useful! It also allows us to define a new variable width in a function and use it differently from the sketch’s width. When the function returns, the outer scope width is unaffected – so scope can also keep our declarations safe from the things we call.

private (vs public) in practice has been used by Processing core devs to prevent people from building sketches and libraries by directly referencing internals that are considered unreliable / dangerous or likely to change.

If you search the Processing source code, you will find private everywhere, but is one representative example:

There was a string variable – it was undocumented, but set to public, yet it apparently isn’t safe to use unless certain conditions are met. Possibly someone started using it – possibly on purpose, possibly due to a typo – and reported a bug, so it was set to private. Use the public method instead! Hands off the variable! This is for PApplet to use internally, it is not for you.

1 Like
10
  • Actually it’s always been totally safe to use it directly.
  • Field sketchPath is the base folder path for all Processing’s load & save methods.
  • Some reasons why sketchPath should be public again in order to allows us to fix Processing’s glitches by ourselves:
  1. When we instantiate our own PApplet sub-sketch, its sketchPath points to a wrong path by default and needs to be fixed by assigning the main sketch’s sketchPath to sub-sketch’s.
  2. Occasionally we may decide to have another folder as our load/save base rather than the default.
11

Sure, not trying to start an argument about whether this particular case is justified – my point here is that the example and its comment demonstrates how “private” is about developer control (even if that is often a point of contention).

Some design philosophies would say “never make anything private” – maximum tinkering. I’m a tinkerer, so I’m not against that. However everything that is public is the API – the programming interface – and small teams with huge APIs may have pragmatic reasons for wanting to keep the interface as small as possible.

There are also some design patterns and philosophies that teach people to make variables / properties private always or almost-always. In OOP, one big one is encapsulation, which in Java might mean handling a variable with getters and setters. So public String sketchPath() = good, public String sketchpath = bad (according to that design logic). However, these can be guidelines, not laws. Processing is sometimes one way, sometimes another. For example, PVector exposes x and y directly (vec.x, not vec.getX()), but Table does not expose its internal rows array as table.rows.

A standard way to route around anything private in open source is to fork the codebase, change the field(s) to public, and build. It can be a pain, but then you have a PDE with any exposed internals you like – although only for you.