Comments (4)
You are right about the JIT having an easier time with immutable classes, but until I hear something about records being additionally optimized or otherwise treated specially by the JVM more than just normal immutable value classes, I think I'll put first class support for records in the core on hold.
I wouldn't mind playing around with the code to emit the minimal bytecode required for a record.
Sounds like a useful feature, maybe you could call your implementation defrecord--
? :)
Now that I think about it, if we eventually do support records, something like you've mentioned may really just belong in a different namespace like insn.record
, or maybe another library altogether for higher-level constructs (kind of like how ASM provides convenience methods with GeneratorAdapter
). Maybe if you make any progress on this, your work could be the initial start to a new companion library? (Although, I'd need to expose visitRecordComponent
in the core to enable 100% compliance with the Java compilation.)
Anyway, thanks for opening this. We can leave it open for the time being for any additional discussion.
from insn.
Another thing to keep in mind which will be different in terms of bytecode and JVM representation is primitive classes (so records are defrecord- while primitive records will be --)
https://openjdk.java.net/jeps/401
Still a candidate, but looming on the horizon
from insn.
I did take a look at records a bit the last time I bumped the ASM version. At that time, I wasn't exactly sure what utility emitting records from Clojure would have, other than just emulating Java/javac
. Please correct me if I'm wrong, but as far as I can tell, there's no special synthesis/magic about records at the JVM level; they're essentially just syntactical sugar for immutable value classes coupled with some boilerplate methods.
It seems like this might be a worthy addition, and with a minor change to support primitives (:iload
, double-width types, etc.), your constructor function seems good (thanks!). However, after again reading the javadoc and taking a cursory look at the bytecode, I think that if we did do this, a hypothetical user of this feature might additionally expect the field accessor methods, along with equals
, toString
, et al., to be auto-generated and work similarly, as well. So I'm not sure right now what is best.
Also, I'd be curious to know if you have a use case for emitting records that I may have missed?
Thanks.
from insn.
First, you are correct regarding some of the methods I neglected. That was my oversight, I simply didn't read the bytecode fully, instead focusing on the constructor.
With regards to the meat of the question:
there's no special synthesis/magic about records at the JVM level
I think records are slightly different at the jvm level than regular classes. I wasn't able to find it with a cursory glance at the source code, but iirc them being immutable value classes makes things easier for the JIT compiler, but I'm not sure.
I wouldn't mind playing around with the code to emit the minimal bytecode required for a record. Seems like a fun way to get to know the library, but with regards to the use case, the motivating example was about 80% intellectual curiosity, and 20% wondering if records could play well with Clojure. A particular use case could be that Clojure collections make for terrible hash map keys. Nominal tuples which already implement hash and equality would let us use compound keys with significantly less overhead.
from insn.
Related Issues (13)
- Clojure AOT compilation bug HOT 1
- Question: how to express call to default method of interface HOT 6
- Upgrading to 0.5.3 causes `Constant pool index 75 is invalid` HOT 3
- Static invocation inside if branch, possible issue or just doing wrong? HOT 4
- Can insn output signatures? HOT 5
- Minimal example getting errors (newb) HOT 2
- I love this library HOT 4
- How to use labels? HOT 2
- saving out .class files HOT 3
- try finally HOT 4
- static initializer section HOT 2
- Support for setting the SourceFile attribute of the class HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from insn.