Feedbacks to design native memory methods
elect86 opened this issue · 0 comments
So, I'm getting some dilemmas right now and I'd like to hear some feedbacks
I finally recently implemented inline classes into native pointer management in kool (I was eager to do it, but always postponed because of other priorities)
Where you basically can do something like:
val intPtr = IntPtr(x) // x is a valid, already allocated area of memory
intPtr[1] = 5
val r = intPtr[0]
all for free, offsets are set accordingly to the pointer type
Now I already used that in the vkk playground (tmp branch) and I went for expliciteness, so write(adr: Adr)
or write(stack: MemoryStack)
to write the current struct
at the given memory address or in the given MemoryStack
. On the other side, constructor(ptr: BytePtr)
s and read/native { }
methods to read from native memory.
Here in glm, there was only some raw simple methods
// Vec2
infix fun to(ptr: Ptr) {
memPutFloat(ptr, x)
memPutFloat(ptr + Float.BYTES, y)
}
// Vec2 companion object
fun fromPointer(ptr: Ptr) = Vec2(memGetFloat(ptr), memGetFloat(ptr + Float.BYTES))
I'm planning to expand this area, by providing a constructor
constructor(ptr: FloatPtr) : this( { i -> ptr[i] } )
calling the corresponding functional programming constructor
This will work for all the vector and matrices, except the vectors using Long
s (Vec1l
, Vec2l
, Vec3l
and Vec4l
), because they have the convenience constructor accepting just one Long
, whose signature will clash with construct(ptr: LongPtr)
. In this cases, I'll keep the convenience constructor and renounce to the pointer one.
I'm incline to accept this small incoherence for these vectors type and provide a static method for those.
This is my first dilemma.
Second issue is the naming. At the begin I thought to go with to
for writing and from
for reading into an existing class (constructor otherwise).
But a part of me is pushing for explicit read
and write
methods.
What do you think, guys?