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 gets
generated and that includes structs.
@Jason E. Aten
> *> // Declare a new type that embeds the generated.Respons*
> *> type EnrichedResponse generated.Response*
> and this is not type embedding, it is just a type definition
You are correct. Sorry for the confusion the doc comment caused. This is
indeed a type definition. This was meant as a connection to the alternative
I pointed out:
Make *EnrichedResponse* a struct embedding *generated.Response *and add
more state like this:
*type EnrichedResponse struct {*
* generated.Response*
* additionalState int*
*}*
Then* Enriched* is trivial:
*func (r *EnrichedResponse) Enriched() int { return r.**additionalState*
*}*
And it is trivial to add the new state but returning it is impossible:
*func (h *handler) Get(ctx context.Context, request *generated.Request)
(*generated.Response, error) { enriched := EnrichedResponse{*
* Response: ....,*
*additionalState: 42,*
* }*
* response := generated.Response(enriched)*
* // ^^^^^ WILL NOT WORK*
* return &response, nil}*
But then I cannot do the conversion as the types have different memory
representations. Wagner's first suggestion points to ways around this.
@Axel Wagner
The global map is something I also thought about but it introduces
contention and is generally ugly. The usage of weak.Pointer-s also guards
against cases when Response is not comparable. But this would be a bad
solution.
The *unsafe.Pointer* is a cuter and enticingly evil way. But in the end -
it is explicitly opting out of type safety. The return of the unnamed
struct is nice!
Is the equality of pointer to struct and pointer to its first member
actually always guaranteed by Go lang?
https://go.dev/ref/spec#Package_unsafe says The effect of converting
between Pointer and uintptr is implementation-defined but I guess it is not
the same thing. The sections on Struct types and Alignment do not give such
guarantees.
In the end it is not wise to use such a technique on a large code base
shared by many developers. I will not be going this way but many thanx for
the example it taught me something I did not know.
Axel, you may use it for a 2nd part of Advanced Generics Patterns (nice
presentation! I liked it) - Advanced Type Patterns (use types wrongly so we
can learn how to make the wrong way the right way).
I was hoping that there is a trick that I am missing. Like - a returned
function can access state in a closure but I see no way to do it for
methods. I definitely do not want to go the direction - since I want to add
a method I should change the code generation, types (struct vs
interface-s) to suit that small change.
Kind regards:
al_shopov
На пн, 12.05.2025 г. в 7:12 Axel Wagner <axel.wagner...@googlemail.com>
написа:
> On Mon, 12 May 2025 at 07:05, Axel Wagner <axel.wagner...@googlemail.com>
> wrote:
>
>> A less evil, but still bad way, would be to store it in a global map:
>> https://go.dev/play/p/ZHBJVCduf25 (note: I'm not sure this use of weak
>> pointers is actually correct, I haven't used them yet).
>>
>
> Okay, I'm pretty sure it's not correct. It should be possible to make this
> work somehow, but I'm a bit too lazy to try right now, especially as you
> shouldn't do it anyways.
>
>
>> Otherwise, no. The state has to live somewhere. And really, both of these
>> tricks are still really bad and you shouldn't do them. The best way is to
>> respect the type system and if you want extra methods, you need a new type
>> and if that needs extra state, that should be stored in the type.
>>
>> -----
>>> Why would I want to do this? What am I trying to achieve?
>>>
>>> Basically there is a lot of generated code and I want to keep
>>> compatibility with it.
>>> Similar to the way Go embeds wider interfaces into narrower ones I want
>>> to be able to add methods to the generated code without having to change it.
>>
>>
>> Change the code generator, and/or add additional code in an extra file.
>> Hacking the language will cause you more pain, in the long run.
>>
>>
>>> Then - whenever some code calls the *Get* method on the server - based
>>> on the whether the returned value implements the *Enriched* interface
>>> or not and the value it returns - I can dispatch behavior.
>>>
>>> Kind regards:
>>> al_shopov
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> To view this discussion visit
>>> https://groups.google.com/d/msgid/golang-nuts/bbe6bcd8-e33c-41bf-868a-e498561c3e72n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/bbe6bcd8-e33c-41bf-868a-e498561c3e72n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/golang-nuts/CAP6f5MkQwL%2BnbidAH6P246T%3Do--mL10jAEnR%3DuP8JcG21VLqhw%40mail.gmail.com.
