Skip to content

Feedbacks to design native memory methods #13

@elect86

Description

@elect86

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 Longs (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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions