Generate Opcode3xx.java instead of hand coding. - #461

Thanks for this Frank. Agree on JUMP_BACKWARD_QUICK . It must've slipped by before I understood YAGNI.

Interesting idea that might save time in future. (The edit from opcode.h isn't difficult.) I haven't tried it yet, I will, but I've read it carefully. And is this hand-crafted or are we criticising a coding assistant here?

Good that it seems to create the JavaDoc as in the current. (I have a poor memory for what I wrote, and less for others' work, so I need the IDE to tell me.) And generally it fits in well with other things in the build.

I think it would be sensible to pick up the target Python version from Python. When Gradle runs, that's always the target version. What happens here, I think, is you hard-code it in the file, then it complains if it doesn't match.

Use of multi-line f-strings (probably with some re-indent logic) would help readability and if we have to reflow and paste back some of the fixed Java text. I wasn't that keen on calling p() on every line.

More to say when I've seen it run, I expect.

Thanks for this Frank. Agree on JUMP_BACKWARD_QUICK . It must've slipped by before I understood YAGNI.

Interesting idea that might save time in future. (The edit from opcode.h isn't difficult.) I haven't tried it yet, I will, but I've read it carefully. And is this hand-crafted or are we criticising a coding assistant here?

This is more code assistant than hand-crafted, but I do read every line for understanding and edit if it goes against my taste before I submit - having a reviewer be the first human that sees code is a grave sin. Also I take full responsibility for any code in a PR so criticize away and I will make changes as needed. I completely agree on a second look that the p() stuff is hard to read. For the near term probably all of my code is going to be at least part code assistant - I'm trying this style on for size. Even if I do hand right everything for a given task I would definitely have an LLM based tool review it before I'd let any human look at it - that step has saved me too many times now :)

Good that it seems to create the JavaDoc as in the current. (I have a poor memory for what I wrote, and less for others' work, so I need the IDE to tell me.) And generally it fits in well with other things in the build.

I am doing my best to conform to the standards you have been setting for JavaDocs and comments in general. In the past I have definitely slacked in these areas.

I think it would be sensible to pick up the target Python version from Python. When Gradle runs, that's always the target version. What happens here, I think, is you hard-code it in the file, then it complains if it doesn't match.

Use of multi-line f-strings (probably with some re-indent logic) would help readability and if we have to reflow and paste back some of the fixed Java text. I wasn't that keen on calling p() on every line.

More to say when I've seen it run, I expect.

Bit slow getting back on this. Thanks to your renewed interest, I've realised how far ahead VSJ has got since I started the modularisation. I want to get that code over here, so that new contributions build on it. For example, a lot more of these opcodes have implementations.

Note here: #375 (comment) with commits to follow.

Good that it seems to create the JavaDoc as in the current. (I have a poor memory for what I wrote, and less for others' work, so I need the IDE to tell me.) And generally it fits in well with other things in the build.

I am doing my best to conform to the standards you have been setting for JavaDocs and comments in general. In the past I have definitely slacked in these areas.

javadoc is incredibly fussy these days. I have let it bully me into a high standard for the code itself, but I can't bring myself to do the same for test code. I wish it had a half-way point where you could add a description without being forced into all that @param. Sometimes it has made me look a second time at code that was actually in error (an over-hasty paste). Mostly I appreciate the increased support I get in the IDE. The Javadoc tab is permanently open when I'm creating. (Also, have you noticed Stefan's APIdia?)

On coding standards generally, for Jython 2 I'm sticking pretty close to the standard Josh Juneau set for the project, interpreted by me into an Eclipse formatter spec. For Jython 3 I'm more permissive, but it relies on features in the Eclipse formatter that may not be reproducible. For example, a feature I value is that while I use the same width we always have for code, it will wrap comments to a more readable width counting from the indent.

VSCode reads, but cannot hep you prepare :-(, Eclipse formatter specs. It supports most of the features that matter, but then the Eclipse one seems not to be 100% conformant either.

All looks good to me. Thanks @fwierzbicki !