This is a great practical generics example. Thanks for sharing!
On Sunday, 3 January 2021 at 16:35:38 UTC-8 aphill...@gmail.com wrote:
> I am an avid user of Go who loves how it makes my life so much easier due
> to its amazing simplicity. I am thrilled to find that a great deal of
> progress h
Reading
sync.Map[string]linked.List string
I have no idea what that represents?
What if you had a map of maps - which is a very common data structure -
possibly with completely different key and value types? Really any nested data
structures with multiple types would be impossible to read IMO.
What is the "them" to be omitted if there is only one type parameter? It
wouldn't make sense to omit the brackets (because there needs to be some
delimiter between the name of the generic function/type and the type
argument). But if there is only one type-parameter anyway, I don't know
what else yo
I think something like sync.Map[string]linked.List string is more readable than
sync.Map[string, linked.List[string]].
I propose putting the last type parameter to a generic type after the square
brackets and omitting them when there is only one type parameter.
--
You received this message bec
On Mon, Jan 4, 2021 at 8:09 PM ChrisLu wrote:
> Hi,
>
> For a list of json objects, the key names are usually repeated.
> e.g., {:1, :2},{:2, :3}, ...
>
> The key names, "" and "" for the above example, could be very long.
> Is there any existing library already encode jso
An AST (Abstract Syntax Tree) is exactly what the common output of a parser
is, and you can see an example of it in the Go source code. But not always
- the output of a parser can also be function calls, as in a streaming XML
(SAX) style parser.
The important elements of a parser is that it kn
It is not JSON at that point - and if you want a JSON compatible format
that compresses, well, there are dozens of them - some just elide the
keynames, others include compression of the data elements as well. Here is
an article discussing a lot of
them:
https://www.lucidchart.com/techblog/2019
Hi,
For a list of json objects, the key names are usually repeated.
e.g., {:1, :2},{:2, :3}, ...
The key names, "" and "" for the above example, could be very long.
Is there any existing library already encode json objects via a dictionary?
This is a JSON-specific compres
I posted two real world problems where Generics would be useful to me,
earlier in the thread. Saw no response, and now continued claims that no
real world problems have been provided? I'm not sure if that is
disingenuous, or merely an artifact of the client someone is using causing
replies that
On Mon, Jan 4, 2021 at 9:20 AM Volker Dobler
wrote:
> On Sunday, 3 January 2021 at 18:43:22 UTC+1 ren...@ix.netcom.com wrote:
>
>> I do believe (hope) David was kidding. Anonymous product types (and
>> similar constructs) are the root of all evil.
>>
>
> Yes, you need dependent product types. Esp
On Sun, Jan 3, 2021 at 6:32 PM roger peppe wrote:
> FWIW I'm certain that the lack of tuples in Go was a very deliberate
> decision - one of Go's more significant ancestors, Limbo, had tuples.
> Anonymous product types have their disadvantages too (you don't get to
> name the members, so code can
> On 3 Jan 2021, at 9:15, atd...@gmail.com wrote:
>
> Hello,
>
> I am currently in need of a css stylesheet parser to retrieve the CSSOM as a
> go datastructure.
> (probably in a map[*selector* string]map[*cssproperty* string]interface{})
>
> The existing Go libraries that can be found onli
On Sunday, 3 January 2021 at 18:43:22 UTC+1 ren...@ix.netcom.com wrote:
> I do believe (hope) David was kidding. Anonymous product types (and
> similar constructs) are the root of all evil.
>
Yes, you need dependent product types. Especially anonymous ones.
(Just be be clear: I _am_ kidding.)
V
13 matches
Mail list logo
