We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.
IndexProcessing DevelopmentLibraries,  Tool Development › Extending vs. Passing PApplet
Page Index Toggle Pages: 1
Extending vs. Passing PApplet (Read 3560 times)
Extending vs. Passing PApplet
Apr 20th, 2005, 6:51am
 
When creating a new library, is it preferable to simply extend PApplet (to get access to the Processing core methods) or pass a PApplet parent (seems syntactically weird, but allows registration of draw, size, etc.)?

(edit)
What I'm trying to avoid is code like the following within sketches:

Code:
Camera cam1 = new Camera(this, 0, 0, 200); 



I'm guessing that the average P5 user won't understand what "this" is for (a reference to the parent applet).
Re: Extending vs. Passing PApplet
Reply #1 - Apr 20th, 2005, 4:34pm
 
The code you show is quite standard in regular Java programming, even though it is considered bad coding practice and against the OOP philosopy.

I haven't tried it, but it seems logical that you will need a PApplet reference to access the internal state of the parent applet (i.e. size, drawing commands etc). Something to be wary of is whether or not properties of PApplet are public or private, since your library won't be able to access them even through an object reference.
Re: Extending vs. Passing PApplet
Reply #2 - Apr 20th, 2005, 8:09pm
 
Right, I've experienced this style before, especially in AWT applications (which makes since why we'd see it again here). I was just wondering if there were some way to getDefaultEnvironment() or getBaseApplet() or some-such similar method tucked away in core. If it doesn't exist, should it exist so that we don't surface odd syntax to the average P5 user?

Maybe the consideration is that the "average" P5 user won't be using libraries, so this structure is OK.

Thoughts?
Re: Extending vs. Passing PApplet
Reply #3 - Apr 20th, 2005, 8:18pm
 
we don't like having to use "new" and "this", it was a long debate for the new libraries, but in order to keep things fundamentally separate, it's what we had to do. even if we dynamically loaded the code for Serial, the best we could do would be:

Serial s = (Serial) createSerial("COM1", 9600);

which we decided for having added code, isn't much better than

Serial s = new Serial(this, "COM1", 9600);

there's no way to get the "default" PApplet because there's no such thing. you can't make it static, because then every applet on a web page (or in some cases, in an open browser in any tab), or if you're using several PApplets as Components in an application, things would get completely horked.

we also considered introducing new syntax, but there's really not a good way to do it, so we figured just telling people to use "new" and "this" won't hurt too badly. sometimes there are archaic things in programming and this will just be one of them. we've tried to get rid of as many as possible but unless there's a clearly far better solution, we stick with the standard method (new, this).
Re: Extending vs. Passing PApplet
Reply #4 - Apr 20th, 2005, 10:44pm
 
I remember talking to Toxi about what he'd like to see in Processing and he said: "More OOP". Heh. Maybe a writeup on "how to write a library" is in order, but it's hardly a priority right now.
Re: Extending vs. Passing PApplet
Reply #5 - Apr 21st, 2005, 12:00am
 
we're leaving the oop to everyone else.

would you believe that how to build a library is inside the "libraries" folder, and it's called "howto.txt"?
Re: Extending vs. Passing PApplet
Reply #6 - Apr 21st, 2005, 12:17am
 
ok, that's the second time today I didn't check the manual and/or the most likely places. I feel like bart in the opening sequence of simpsons, writing "I will not bother fry" a hundred times on a blackboard...

doh!
Page Index Toggle Pages: 1