|
»
»
Changing the way we handle class names in the compiler
|
View:
New views
6 Messages
—
Rating Filter:
Alert me
|
 |
Changing the way we handle class names in the compiler
by Frank Wierzbicki
::
Rate this Message:
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", "Lorg/python/core/PyObject;"); In JRuby style, these would look like this: code.invokespecial(p(PyFunction.class), "<init>", sig(void.class, PyObject.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 quickly. 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? -Frank ------------------------------------------------------------------------------ Come build with us! The BlackBerry® 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-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Jython-dev mailing list Jython-dev@... https://lists.sourceforge.net/lists/listinfo/jython-dev |
|
|
Re: Changing the way we handle class names in the compiler
by Tobias Ivarsson
::
Rate this Message:
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). /Tobias On Fri, Oct 2, 2009 at 3:01 AM, Frank Wierzbicki <fwierzbicki@...> wrote: Hi all, ------------------------------------------------------------------------------ Come build with us! The BlackBerry® 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-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Jython-dev mailing list Jython-dev@... https://lists.sourceforge.net/lists/listinfo/jython-dev |
|
|
Re: Changing the way we handle class names in the compiler
by Frank Wierzbicki
::
Rate this Message:
On Fri, Oct 2, 2009 at 2:41 AM, Tobias Ivarsson <thobes@...> wrote:
> 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). There is a second benefit -- having our compiler use the same conventions as the JRuby compiler increases the chances that we'll find some section of JRuby's compiler that can be broken out and shared... that's my ulterior motive here. Even if that turns out to be a lost cause, we'd still have the more readable codebase. -Frank ------------------------------------------------------------------------------ Come build with us! The BlackBerry® 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-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Jython-dev mailing list Jython-dev@... https://lists.sourceforge.net/lists/listinfo/jython-dev |
|
|
Re: Changing the way we handle class names in the compiler
by Charlie Groves
::
Rate this Message:
On Thu, Oct 1, 2009 at 6:01 PM, Frank Wierzbicki <fwierzbicki@...> wrote:
> 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? I like anything that gets these to be consistent, and this seems like a decent enough convention, so I say go for it. Charlie ------------------------------------------------------------------------------ Come build with us! The BlackBerry® 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-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Jython-dev mailing list Jython-dev@... https://lists.sourceforge.net/lists/listinfo/jython-dev |
|
|
Re: Changing the way we handle class names in the compiler
by Jim White
::
Rate this Message:
What keeps you from using the class name identifier as the class
constant? Are you really required to specify the .class member? I'm thoroughtly ignorant of Python (and Ruby) syntax and identifier rules, so I know this question is entirely from left field... Jim Frank Wierzbicki 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", > "Lorg/python/core/PyObject;"); > > In JRuby style, these would look like this: > > code.invokespecial(p(PyFunction.class), "<init>", sig(void.class, > PyObject.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 > quickly. > > 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? > > -Frank ------------------------------------------------------------------------------ Come build with us! The BlackBerry® 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-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Jython-dev mailing list Jython-dev@... https://lists.sourceforge.net/lists/listinfo/jython-dev |
|
|
Re: Changing the way we handle class names in the compiler
by Frank Wierzbicki
::
Rate this Message:
On Sat, Oct 3, 2009 at 8:36 PM, Jim White <jim@...> wrote:
> What keeps you from using the class name identifier as the class > constant? Are you really required to specify the .class member? > > I'm thoroughtly ignorant of Python (and Ruby) syntax and identifier > rules, so I know this question is entirely from left field... This stuff isn't really about Python or Ruby -- the compilers of each emit raw bytecodes which take strings like Lorg/python/core/PyObject; to describe the name of a particular class. Because it's inconvenient to type strings like that all over the place, the current Jython compiler uses a few constants. The above string is held in a constant called $pyObj. The problem comes in because every class doesn't have a $ constant name, so there's a mix of long names and shortcuts. The mix makes it a bit hard to read. The JRuby guys have some simple shortcuts that take arguments like PyObject.class and return Lorg/python/core/PyObject; -- once applied consistently, things will be easier to read. -Frank ------------------------------------------------------------------------------ Come build with us! The BlackBerry® 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-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Jython-dev mailing list Jython-dev@... https://lists.sourceforge.net/lists/listinfo/jython-dev |
| Free embeddable forum powered by Nabble | Forum Help |
