Gentle ping on this.
If this is not wanted, then say. Otherwise, I will create an issue on
https://github.com/golang/go to reach out to the relevant folk directly.
Regards,
Tom
On Wednesday, April 23, 2025 at 1:11:22 AM UTC+2 twp...@gmail.com wrote:
> tl;dr importing golang.org/x/crypto/x509ro
That’s interesting on the performance of sync.Map as the issues cited here are still open https://github.com/golang/go/issues/28938#issuecomment-441681208On May 12, 2025, at 12:48 PM, Jason E. Aten wrote:Robert's suggestion is obviously the most direct and correct route if you can change the IDL
Robert's suggestion is obviously the most direct and correct route if you
can change the IDL of generated type. After all, code generation is there
to simplify generating alot of code from a little definition.
I was assuming that one of constraints was not being able to modify the
struct receiv
Why not just modify the code generator to add a user data pointer to the structure?I can’t imagine something like that isn’t already there? Either the code generator should be easy to enhance or it should have a side car data field - anything else is hard to rationalize as even rudimentary design.
Now that I think about it again - I guess your suggestion could work for my
case with some caveats:
1. There can be contention on the map - but as you point out there is
sync.Map as well
2. The state should be removed from the map but that can also be arranged
by deferring a delete operation
3. If
Forgive me if this off base, as I'm still a little fuzzy on the exact
constraints
of you problem... but, as stated, if you want
to associate additional optional behavior and state with any given response
that is constrained to the generated, just use
the responses's pointer (to its struct) (if lo
seems a very common assumption
I would have guessed it is due to compatibility with C but
https://pkg.go.dev/cmd/cgo#hdr-C_references_to_Go explicitly states:
*Go struct types are not supported; use a C struct type. *
So it may be completely at the decision of the implementer.
The caveats in http
Hello all and thanx for the answers. Here I provide more information:
@Robert Engels
| Just have the parameters be interfaces and do reflection/type casting.
I sadly cannot do this (at least right away). That is why I asked for help.
I cannot guarantee the parameters are interfaces - they are what
