Take the 2-minute tour ×

Although I do somewhat understand the reasons behind it, I find LWJGL's splitting of OpenGL methods and values across numerous classes rather annoying. Since I prefer dealing with functions anyway, I'm currently writing a Clojure module that exposes the OpenGL 3.3 core functions and constants in a single namespace.

Now the problem is, some OpenGL functions have overloads in LWJGL like for instance glBindAttribLocation has one for ByteBuffer and one for CharSequence. Now I'm saying 'problem' in the broadest sense because I'm not sure yet whether this really is one.

Can I for instance just write

(defn glBindAttribLocation [program index name]
  (GL20/glBindAttribLocation program index name))

and trust that Clojure will figure out which overload to call, or do I have to do this manually with some typehint-uglyness?

On the same note, many of LWJGL's functions take floats or ints - but I hear Clojure itself only uses long and double (of the primitives that is). Does that mean that everytime I call one of these functions, whatever I have gets converted to an Integer (Float) and then from there to an int (float) whenever I call one of these functions?

share|improve this question
The conversion is probably directly long->int and float->double, if that is any consolation :) Calling overloaded functions really is a drag and there is no help about it. –  Marko Topolnik Oct 9 '12 at 15:32
add comment

2 Answers

Yes, you will likely need to coerce data to type proper type if there are multiple candidate methods for an invocation due to overloading. The good news is that the Clojure compiler will likely raise an error, rather than give you surprising behavior.

See: Clojure overloaded method resolution for Longs

share|improve this answer
That seems to be a problem particular to Longs. The LWJGL library only uses int and float, the overloads are things like ByteBuffer vs CharSequence vs CharSequence[] –  Cubic Oct 9 '12 at 15:42
Not quite. You can still get a warning such as Reflection warning, call to <class method-or-ctor> can't be resolved. when the compile-time type is ambiguous. –  noahlz Oct 9 '12 at 15:46
add comment

I've had weird problems with long->int conversion, but only when there is an overloaded signature for both int and long, creating ambiguities. If there are only methods for int and float (which, from looking at the documentation seems to be the case) then you should be fine. Clojure will automatically do the long->int and double->float conversions:

user=> (Float/isInfinite 5.0) ; Takes a float
user=> (Integer/numberOfTrailingZeros 4) ; Takes an int

As for GL20/glBindAttribLocation, the only times I've had to cast for overloaded methods are 1) if they have both an int and long version or 2) if I'm passing nil as a parameter for an object, making it impossible to guess which method I wanted. Since the first two arguments must be ints, unless you can pass nil for the name parameter then you should be fine.

share|improve this answer
add comment

Your Answer


