On Sat, Dec 3, 2022 at 11:34 PM burak serdar <bser...@computer.org> wrote:
>
>
> On Sat, Dec 3, 2022 at 8:47 PM Diogo Baeder <diogobae...@gmail.com> wrote:
>
>> Now, imagine this scenario: I have a web application which has to access
>> a webservice that responds with JSON payloads; These payloads are a list of
>> values, where each value is a smaller list like '[20220101, 1.234, "New
>> York"]'. And these smaller lists follow the same type sequence: int64,
>> float64, string. Suppose that I want to filter those values and send a
>> response to the client, with the data structure unchanged (same format and
>> types). Today, it doesn't seem to be possible to do that in Go, unless I do
>> some dirty hack like decoding to '[]any' and then cast to the other types,
>> and then hack again to put these values in the response to the client.
>>
>
> What you described above is a struct.
>
I think the problem Diogo is pointing out is a reasonable one - you specify
the type of the object you're unpacking by e.g. json.Unmarshal(data,
&typedObject), but right now there's no way (AFAIK) for the typed object to
capture "a list of [int, float, string] triples" except by capturing it as
a [][]any and then manually typechecking that each one is indeed an int, a
float, and a string.
It'd be great if, for example, you could tag an entire type like:
type Row struct { `json:tuple`
date int64
score float64
city string
}
so that
var v []Row
json.Unmarshal(data, &v)
would automatically parse the triples into usable structs (and json.Marshal
would turn them back into lists).
*****
I also don't think arguments that Go doesn't need tuples really hold water,
given that Go already *has* tuples, just only for return types. We could
all be writing
func Foo() struct{int, error} {
return struct{int, error}{3, nil}
}
v := Foo()
i, err := v.int, v.error
...
but I think everyone agrees that tuples make this code much more readable.
Given that we all do agree that there are cases where having tuples makes
for better code, I don't actually know why Go doesn't support them in
general. Is it out of fear that people will use them poorly, or is it
actually pretty complex to implement and not worthwhile?
--
Dan Lepage
--
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 on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAAViQtg6ec7u-iHAo4_%3DvgbcrLLN6-%3DNW-argB_3U8prJ_5cMQ%40mail.gmail.com.
