Go for it!   I'm in a "branch" anyway (where I do similar stuff), so it will not cause trouble for me.

If we wanted we could even have a the "code" object have the following signatures:

public void invokespecial(Class<?> target, String methodName, Class<?> returns, Class<?>... args);

But the p(...) sig(...) division has the benefit that you can create the signatures on beforehand and reuse them if generating them over and over turns out to be a performance issue (although with simple enough code hotspot should turn it into a constant anyway).


On Fri, Oct 2, 2009 at 3:01 AM, Frank Wierzbicki <fwierzbicki@gmail.com> wrote:
Hi all,

I'm considering adopting the class name/signature name conventions
used in JRuby, because I find them more readable than the style we
currently use.  Our current usage is a mix of explicit string versions
like "Lorg.python.PyObject;" and "org.python.PyObject", and constants
like $pyObj that are used inconsistently.

A couple of examples from our current code:

code.invokespecial("org/python/core/PyFunction", "<init>", "(" +
$pyObj + $pyObjArr + $pyCode + $pyObj + ")V");
code.getfield("org/python/core/PyException", "value",

In JRuby style, these would look like this:

code.invokespecial(p(PyFunction.class), "<init>", sig(void.class,
   PyObject[].class, PyCode.class, PyObject.class));

code.getfield(p(PyException.class), "value", ci(PyObject.class));

This style does not always make the call shorter (though it often
does) but I think it makes them easier to read.  See any of the
compiler classes in JRuby and compare them to ours.

Note the very short functions like "p", "sig", and "ci".  They are a
bit opaque at first, but in JRuby's compiler (and ours if we switch)
they are used so extensively in the compiler that you get used to it

The point is that they are easy to apply consistently, you don't need
to choose between adding a constant to ClassConstants.java or spelling
out the particular string representation of the class you are on.

What do you think?  Will this cause any trouble for those of you doing
compiler work?


Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
Jython-dev mailing list