<gamester>
daurnimator: The @sizeOf opaque types is unknown. Everything would break down if the language supported storing opaque types. The 'self' parameter would have to be a pointer. You couldn't store the struct by value. Etc. To wrap you'll have to store a pointer to the Opaque.
hio has quit [Quit: Connection closed for inactivity]
<Barabas>
Although I do like zig's build in test functionality I do find it hard to read the 'actual' code sometimes, because all the code used for testing is mixed in in the same file.
<daurnimator>
Barabas: howso? the test blocks are quite well marked IMO...
<Barabas>
Sometimes because the testing code is larger than the implementation and the implementation kinda drowns in the testing code.
<Barabas>
Sometimes because there are helper functions for the tests.
<andrewrk>
doc generation will help with this
<Barabas>
Yes, definitely.
dewf has quit [Quit: Leaving]
<daurnimator>
andrewrk: saw your reply. is there a recommended solution for adding methods to an opaque struct?
<daurnimator>
I guess wrap a pointer to it instead?
<andrewrk>
There is no way to add methods to an opaque type
<andrewrk>
What are you trying to do, big picture?
<daurnimator>
andrewrk: thinking about writing "bindings" to existing C libraries
<daurnimator>
andrewrk: they may only have an opaque struct, and I want to add methods to it in zig.
<andrewrk>
Bindings aren't supposed to be necessary in Zig, and monkey patching is purposefully not allowed. You're fighting against the language in 2 ways
<daurnimator>
andrewrk: why no bindings?
<andrewrk>
Why bindings?
<daurnimator>
when using e.g. lua from zig, I would be happy using bindings that allow: `myluastate.pushslice(myzigslice)` rather than the C equivalent: `lua_pushlstring(myluastate, myzigslice.ptr, myzigslice.len)`
<andrewrk>
I recommend not trying to fight against the lua API
<andrewrk>
Just use it
<andrewrk>
Zig code that uses c libraries looks like C code that uses c libraries
wootehfoot has quit [Read error: Connection reset by peer]
wootehfoot has joined #zig
<daurnimator>
Other places it would be more required. e.g. if I want to create a zig allocator from lua_getallocf
<andrewrk>
daurnimator, why would that require methods on opaque structs?
<daurnimator>
andrewrk: that wouldn't; it was more pointing out that sometimes you *need* bindings
<daurnimator>
(if you want to interoperate with the zig standard library.... which if you're using zig: you should :p)
<Barabas>
If you want to add some convenience functions, just write those imo. Or if you realllly want to wrap it you can store a pointer to the lua state in you wrapper struct
<emekankurumeh[m]>
you usually only have pointers to opaque structs like that anyway
jjido has joined #zig
bheads has quit [Ping timeout: 272 seconds]
SimonNa has quit [Remote host closed the connection]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dd10 has joined #zig
hio has joined #zig
darithorn has joined #zig
dd10 has quit [Quit: Page closed]
return0e has joined #zig
return0e_ has quit [Read error: Connection reset by peer]
very-mediocre has quit [Quit: Page closed]
noonien has quit [Ping timeout: 252 seconds]
noonien has joined #zig
Akuli has joined #zig
Akuli has quit [Quit: Leaving]
Ichorio has quit [Ping timeout: 268 seconds]
jjido has joined #zig
SimonNa has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
Barabas has quit [Ping timeout: 256 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]