in a class say super.line or parent.line with duplicate identifier line?

Chrisir

Hello all,

I have a simple question which has been asked a 1000 times...

In a class I have 2 methods named A and line (PVector p).

In A now I wanted to call line (float,float,float,float) - so the normal line outside the class (and not my new line).

But he says he don't know line (float,float,float,float) . Because identifier line is duplicate.

I know I could

• name line (PVector p) differently or
• instantiate the class with "this" and save the content of "this" in the class as PApplet sketch; (sketch = this) and say sketch.line(float,float,float,float);

but why can't I directly say in the class

• PApplet.line(float,float,float,float);

or

• super.line(float,float,float,float);

or

• this.parent.line(float,float,float,float);

or so?

Thank you!

Greetings, Chrisir

GoToLoop

I have a simple question which has been asked a 1000 times...

It's neither simple nor I've seen it before! [-(

By default, the whole sketch inherits from PApplet. And line() is 1 of its many methods!
This is how we can directly access Processing's framework API w/o any explicit reference! :ar!
And as in any inheritance, our own sketch sub-classe can override and/or overload (polymorphism) the original 1s.

The code below works as expected: :>

void setup() {  // setup() is itself an overridden method!  >:-P
  noLoop();
  line(new PVector(10, 10), new PVector(width - 10, height - 10));
}

void line(PVector xy, PVector ab) {  // overloaded line() method from Processing's API.
  line(xy.x, xy.y, ab.x, ab.y);
}

Since the sketch itself is already a sub-class of PApplet, what happens when we create nested classes? :-?
Would they inherit from and/or considered a PApplet too?
Since nested/inner classes aren't used much outside Processing and most Processing programmers aren't even aware of that;
the answer might surprise most of us! >-)

I've already dabbled at that in the old forum, seeking for a hacked way to force Java classes get multiple inheritance.
What I've found out is that nested classes internally accumulate inheritance as they get deeper.
But externally, they only inherits from the immediate parent class! @-)

Therefore, our Processing's custom classes inherits from the sketch's top-class w/ all of its accumulated methods & fields.
However there's a paradox, they aren't considered PApplet! So it's like a Frankenstein incomplete PApplet subclass! :O)

Dunno why, but due to their fragile & freakish distance inheritance, if we dare to overload a PApplet method,
we ended up completely breaking it!

/**
 * Overloaded Multi-Inheritance (v1.01)
 * by  GoToLoop (2014/Mar)
 *
 * forum.processing.org/two/discussion/3502/
 * in-a-class-say-super-line-or-parent-line-with-duplicate-identifier-line
 */

// Nested class MyLine have everything from PApplet. But even so it's not a PApplet!

final PApplet pa = new MyLine();  // Fails!!!

void setup() {  // setup() is itself an overridden method!  >:-P
  noLoop();
  line(new PVector(10, 10), new PVector(width - 10, height - 10));
  new MyLine().line(new PVector(width - 10, 10), new PVector(0, height - 10));    // Fails!!!
}

// The method below belongs to the sketch top-class, which explicitly inherits from PApplet.
// Overloading works alright. We can still invoke the original line():

void line(PVector xy, PVector ab) {   // overloaded line() method from Processing's API.
  line(xy.x, xy.y, ab.x, ab.y);
}

// Gets everything including PApplet's methods & fields. But it's not a PApplet class:

class MyLine {
  void line(PVector xy, PVector ab) { // overloading here destroys fragile far-away inheritance!
    line(xy.x, xy.y, ab.x, ab.y);  // Fails!!!
  }
}

Chrisir

thank you so much

My issue is with line30!

How can I make it so that he doesn't look inside the class for the function line but outside of it?

Like parent.line or super.line or this.parent.line...

you are saying it's impossible.

/**

 * by  GoToLoop (2014/Mar)
 *
 * forum.processing.org/two/discussion/3502/
 * in-a-class-say-super-line-or-parent-line-with-duplicate-identifier-line
 */

final PApplet pa=new  PApplet (); // = new MyLine();  // Fails!!!

MyLine ml = new MyLine() ;

void setup() {  // setup() is itself an overridden method!  >:-P
  size(600, 600);
  noLoop();
  //line(new PVector(10, 10), new PVector(width - 10, height - 10));
  // ml.line(new PVector(width - 10, 10), new PVector(0, height - 10));    // Fails!!!
  ml.myTest();
}

//===================================================================================

class MyLine {
  void line(PVector xy, PVector ab) { // overloading here destroys fragile far-away inheritance!
    println ("line");
  }

  void myTest() {
    //line ( new PVector(width - 10, 10), new PVector(0, height - 10) );
    this.super.line(10, 20, 100, 90);  // Fails!!!
  }
}
//

GoToLoop

Your line #9 makes no sense. Why instantiate another PApplet if the sketch itself extends it?! :-/

In Processing's IDE, hit CTRL+E to export a sketch, and look for the generated ".java" file.
There you're gonna see w/ your own eyes that the main sketch indeed extends PApplet! :P

Now about the keyword super. It can only reference the immediate parent class!
The original line() method is 2 classes away, since MyLine is an inner class from the sketch top-class! :-&

Worse, as already explained in my previous reply, the PApplet API is passed on to nested classes as a somewhat collateral effect!
Even though MyLine has access to the PApplet API, it's not officially 1 like the sketch top-class is!
Like I stated, it's a case of disguised partial multi-inheritance! 3:-O

Either overloads line() as a main sketch's method like I did at the 1st example,
or create another top-class rather than a nested class in another tab suffixed w/ ".java" rather than ".pde"! [-X

Chrisir

Thanks a lot!

PhiLho

Let see.

Your problematic class is like:

void setup() 
{
  size(800, 800);

  A a = new A();
  a.f();
  a.line(new PVector(600, 700));
}

class A
{
  void f()
  {
    line(10, 100, 200, 500);
  }

  void line(PVector v)
  {
    line(0, 0, v.x, v.y);
  }
}

Right? I am not sure why the parent class' line is hidden by the redeclaration inside the class, even when they have different signatures.

Anyway, there is a solution, not so well known, because it is rarely used, but it is still useful to know:

class A
{
  void f()
  {
    SketchName.this.line(10, 100, 200, 500);
  }

  void line(PVector v)
  {
    SketchName.this.line(0, 0, v.x, v.y);
  }
}

when SketchName is the name of your main PDE file.

GoToLoop

I am not sure why the parent class' line is hidden by the redeclaration inside the class,...

Function line() and all Processing's API are inherited by the main top-class b/c it explicitly extends PApplet! #:-S
However the inner class A, or in my example MyLine, don't explicitly extend neither PApplet nor the sketch to-class!
They got the API indirectly through some kinda closure. Acting like a partial multi-inheritance.

Since it isn't a real PApplet as I've already proven in my 2nd example w/ this line:

final PApplet pa = new MyLine();  // Fails!!!

how can we expect to overload line() or any of the API functions? #-o

PhiLho

I never wrote that the class was inheriting of PApplet, but being a nested class of a class extending it, it has access to all the methods of PApplet: if the line(PVector) method in my A class is renamed to something else, the sketch just works as expected. That's why I wrote that the original line() is "hidden" by the (re-)declaration in the class.

Chrisir

btw.

the program I was referring to is the class here:

http://forum.processing.org/two/discussion/3520/share-a-class-with-3d-objects-and-a-camera-class#Item_2

since line and point can be used 2D and 3D I was hoping to do this with rect and quad (and a line with extrusion), too.

Just with another number of parameters

now I just named them "line3D" (to avoid the conflict) and not with the same name line (which spoils the experience somehow)

Thanks anyway!

Chrisir

GoToLoop

You don't have to "spoil" your experience. There are 2 solutions if you hadn't been paying attention! #-o

1. @PhiLho's SketchClassName.this.overloadedMethod() technique. Which I confess never seen it before!
   But we'd have to know the ".pde" file's name in order to replace SketchClassName. Not that flexible unfortunately! :(|)

2. And my own fix which you can find as my very 1st example at the top of this thread.
   Merely overload a PApplet method within the main top-class' scope, rather than a nested class! :>
   That's exactly what we do all the time w/ setup(), draw(), mousePressed(), etc. after all! :-j