Processing.js – Something Lost/Gained in the Translation

The nice thing about porting is the end result is already known. Comparing the effects of the original with the effects of the transcription is a good indicator of how close you are and whether or not you're on the right track.

Simple, yes?

Sure, at least in a perfect world where I could have my kitchen faucet yield hot chocolate and have my computer magically upgrade itself to the latest hardware and software. Alas, a perfect, honest-to-the-source, zero deviation transcription may not always be possible; such is what I have discovered while tinkering with pushStyle() popStyle() and boolean().

Below you will find I have not embedded the Pjs examples, instead I shall provide a link to another web page with the example on it. This is because embedding requires minification, and I'd rather not go through the frustration of minifying some of the larger examples. I'll provide screenshots of how the examples look using the Processing Development Environment (PDE) for comparison.

Differences in pushStyle() and popStyle()
The basic Processing reference example looks like this

and can now be reproduced in Pjs (Pjs demo here.)

But take a Pjs demo like this one. See the extra pops at the bottom? You can't do that in Processing. The PDE won't allow the Pjs example code to run; it'll see the extra pops, throw an exception, and refuse to run properly until the extra pops are removed. The closest approximation to the Pjs example Processing will allow looks something like this:

Pjs doesn't really concern itself with catching logical errors in the code. At best it just concerns itself with syntactic errors, and if there are any it simply doesn't paint anything onto the canvas. Saying that, the Pjs version of popStyle() has to be a bit more lax than its Processing counterpart and work with, rather than crash on, extra pop calls.

In this matter the solution is simple. Upon figuring out the pop call is extraneous, Pjs effectively ignores it and carries on. It must be one of the few times burying one's head in the sand actually makes the problem go away!
Differences in boolean()
Moving onto boolean(). Let's start out with showing a basic example based on the one found on the Processing website. It looks like this:


and it too may be reproduced in Pjs (Pjs demo here.) However, boolean() is afar more complicated beast than the basic example would imply. In this case it's a matter of how Java/Processing is very strict on the number and nature of arguments passed to a method, while JavaScript/Pjs is not.

Take for example the following this Pjs demo. Note how we're passing in doubles, booleans, ints, nulls, undefines, etc., and arrays with mysteriously empty elements. If you were to try the code in Processing it wouldn't work. For one, Processing's boolean() refuses to handle boolean variables, or double variables, or nulls, and other fancy things like that. In fact, the closest Processing example to the Pjs demo is rather more sparse and looks like this:


(Un)fortunately, Pjs' boolean() can't take the easy way out and throw away arguments it doesn't like, coughing up an exception, and making the whole show grind to a halt. Being JavaScript it's syntactically correct to pass a cornucopia of dynamically typed arguments into a function. Pjs' boolean() has to handle whatever comes its way gracefully.

As you can tell from the Pjs boolean() demo, I thought this was best done by having the function return "meaningful" results from arguments not normally handled by Processing's boolean(). Numeric arguments are handled like integers: zero values return false, non-zero values return true. Boolean arguments are just returned as themselves. Nulls and undefines return false.

Heresy!
I like to think I've cobbled together an acceptable compromise between how Pjs and Processing behave. I guess I'll find out soon whether this is acceptable or not when I try to push the code into the library.