Timeline for Generating Java Classes with Compile-time Value Parameters
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 15, 2016 at 21:22 | comment | added | Parker Hoyes |
What I think I was really looking for was a more automated solution that produced bytecode similar to method 1, which isn't really possible in standard Java or Xtend. When I ended up doing was using method 2 where the size parameters of these objects needed to be dynamic at runtime, and tediously creating more efficient, specialized implementations for cases where these parameters were static. The implementation would replace the "dynamic" supertype Vector with a more specialized implementation (eg Vector3) if its lifetime was to be relatively long.
|
|
| Jul 15, 2016 at 21:18 | comment | added | Parker Hoyes | The actual project I was working on was a geometry framework to be used in a hyperdimensional renderer. This means I was creating a lot more complex objects than vectors such as ellipsoids, orthotopes et cetera and transformations usually involved matrices. The complexity of working with higher dimensional geometry made type-safety for matrix and vector size desirable while there was still significant desire to avoid the creation of objects as much as possible. | |
| Jul 15, 2016 at 20:35 | comment | added | JimmyJames | Right, as it says, this is based on method 2. Based on your discussion with Groostav with regard to his answer, I got the impression that your concern was not with performance. Have you quantified this overhead i.e. creating 2 objects instead of 1? As for short life-spans, modern JVMs are optimized for this case and should have lower GC cost (basically 0) than longer lived objects. I'm not sure how the metadata plays into this. Is this metadata scalar or dimensional? | |
| Jul 15, 2016 at 20:18 | comment | added | Parker Hoyes |
This is similar to "method 2" in my question. Your solution does, however, give a way of guaranteeing type safety at compile-time, however the overhead of creating a double[] is undesirable compared to an implementation that simply uses 2 primitive doubles. In an example as minimal as this it seems like a microoptimization, but consider a much more complex case where much more metadata is involved and the type in question has a short lifetime.
|
|
| Jul 15, 2016 at 20:13 | history | answered | JimmyJames | CC BY-SA 3.0 |