Suggestion for the Library Basics tutorial: Using Built-in Functions From processing.core

diyoyo

Hi,

I think it would be nice to mention to half-newbies (people comfortable with Processing and wanting to do/learn more hardcore Java), that when you want to call any static method from PApplet, you don't have to write PApplet.myMethod() every time you need it, but instead, you just need to add the following line in the imports:

import static processing.core.PApplet.*;

I spent some time writing (char by char) some classes for my library (the first one I ever make). And because it's been a long time since I have done real Java, I would never remember where from the methods abs() et al. came. I was either replacing by PApplet.sq() or Math.sqrt() depending on my mood. If I hadn't copied and pasted some other code from Processing, Netbeans would never have taught me the trick mentioned above.

What do you think? Should it be added to the tutorial?

Cheers, Yohan.

calsign

Interesting, I had never seen this Java feature before. Upon further reading, it appears that the Processing core might be using the Constant Interface Antipattern. Specifically, take a look at PConstants. The recommended solution with the advent of Java 1.5 (old, but newer than the original Processing) is... static imports.

It might not be all that practical, or relevant for that matter, but the Processing core libraries could switch over to using static imports... it wouldn't be too hard for the preprocessor to add an import static processing.core.PConstants.* at the top of sketches... and this way, the devs could hide some internal variables from the user-end. Something to think about...

Sorry about that tangent... although static imports might be useful, it looks like they can become bad practice:

So when should you use static import? Very sparingly! Only use it when you'd otherwise be tempted to declare local copies of constants, or to abuse inheritance (the Constant Interface Antipattern).

GoToLoop

Interesting, I had never seen this Java feature before.

I've used it 2 times w/ JOptionPane at these threads:

import static javax.swing.JOptionPane.*;

http://forum.processing.org/two/discussion/869/check-array-contents-with-arraylist
http://forum.processing.org/two/discussion/1724/how-to-create-an-interface-asking-username-and-correct-password-

although static imports might be useful, it looks like they can become bad practice:

I've read somewhere that some Java creator repented on including that feature! :-$

... devs could hide some internal variables from the user-end.

I like the way we can hack into Processing!
This isn't a business framework where information hiding is indeed important after all!!! =;

diyoyo

I didn't understand any of your two replies, so it probably means that you made your point, warning me that it should be used with a lot of caution ;)

GoToLoop

If you got a class that most of it are static methods like the famous Math and JOptionPane, go ahead w/ import static!

Just be aware that feature conceals away the origin class of those imported methods. :P
And worse, it can lead to same name clashes for methods & fields among imported classes! :-SS

PhiLho

"_I've read somewhere that some Java creator repented on including that feature! _"
Not me! I rarely use the feature in regular code, but always in unit tests: instead of writing something like:

Assertion.assertThat(var).isEqualsTo("foo");

or

Assertion.verify(fun).calling(Matcher.eq("bar"));

I can write the more readable:

assertThat(var).isEqualsTo("foo");
verify(fun).calling(eq("bar"));

(made up examples, the classes are probably not the real ones...)

"I spent some time writing (char by char) some classes for my library"
Well, if you try identifiers char by char, you are underusing your IDE! Learn the power of Ctrl+Space... :-)

The advice is valuable, but can fit only in the Eclipse tutorial (working for all Java IDEs, mostly).