On 21 Jun 2016, at 19:55, 'Axel Wagner' via golang-nuts
<golang-nuts@googlegroups.com> wrote:
> The issue is, that a "KeyValuePair<K, V>" (no matter if you implemented it
> via generics or like you mention via interfaces) is a fundamentally useless
> type and generics encourage people to add useless types. A "KeyValuePair<K,
> V>" is a "struct { Key K, Value V }", plain and simple. It's not an interface
> and it's not a generic type, it's simply a struct.
>
> I agree, that generics are useful, but they seem to be mainly useful for
> people who write "frameworks", not so much for people who write
> "applications" and so far, go is pretty much a language for the latter.
> Whenever people try to justify generics, they do it from a "I want to write a
> framework" POV - and whenever I miss generics, I do because I'm currently
> writing a framework of some kind.
Not sure that's fair.
For background, I'd quite like generics and liked Ian's last proposal quite a
bit, but I also appreciate the cleanliness of go.
An recent example, in an real life application, where generics would have been
useful is as follows.
I had a cache type thing built around a red-black tree, or more precisely two
red black trees. The items were structs, and I needed one RB tree to be ordered
by time of insertion (then key, for uniqueness), and one by key. One red-black
tree dealt with expiries, and one with finding the item. In the absence of
generics, I needed to embed the struct in a 'ByTime' and 'ByItem' struct, each
of which implement a different 'LessThan' method. And everything that accessed
the trees had a bunch of ugly casting from an interface{} to the relevant type.
This does not make for readable code in any form. A RB tree that was
implemented as a generic (and perhaps took a 'LessThan' function as a lambda)
would have been far far cleaner in *my* code.
So saying it's all about being useful for people who write "frameworks" is
unfair. It would actually have made the application code (i.e. the library
user) far easier to read.
Of course it's possible to generate foolish uses (I would however note in
passing that even with KeyValuePair things might not be as simple as you think,
as it would (presumably) require comparability of K type items); however, it's
also possible to perform stupidity with existing go syntax. The question is
whether generics encourage it.
--
Alex Bligh
--
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.
For more options, visit https://groups.google.com/d/optout.
