On Wed, Jan 20, 2021 at 10:05 AM Jérôme Champion <champ...@gmail.com> wrote:
> A bit out of subject but the naming with generics has always bothered me. > It's more of an general observation and don't have a solution for it. > I think we all agree that naming types and variables is important. Why for > generics we accept that naming them E, K P, T etc.. is good and sufficient? > I think the general rule of thumb I find agreeable is "the length of an identifier should be inversely correlated to the distance between its declaration and its use". Personally, I find code with shorter variable names easier to read (the code structure stands out more), as long as I know what the identifiers are - so I strive to keep them as short as possible, while still retaining clarity of what they are. That leads to above rule of thumb. As type-parameters are always inherently local to the declaration they appear in (and even a method needs to mention them in the receiver), I think it can be argued that they have similar locality to function parameters and should follow similar rules. Personally, that's what I intend to do. For example * If I only use one type-parameter, it doesn't matter - `[T any]` is easy to understand and reading `T` should be clear enough * If I have multiple type-parameters and there is enough context to distinguish them, I will use single-letter names - e.g. `[K comparable, V any]` or `[E Edge, N Node]` seem clear. * If there is not enough context, I will name them, for documentation purposes - e.g. `[Edge, Node any]`. Personally, I intend to use upper-case names, because I am used to consider lower-case names to be a signal that a type is not exported and would find that confusing in documentation. I have always a hard time understanding signature because these one letter > don't give me any context to catch on. (It work for K and V because they > are common and containers are an easy concept to grasp) > Perhaps in go the generic parameters will stay close enough to not be a > problem, but my experience in Java show me it's really hard to understand a > hierarchy of parametrized types and function across multiple files when > they all use the same letters. > And as letters have barely no meaning behind it, they generally evolve in > non controlled way. Not in containers or map/reduce but in some controller > where every now fancy functionality add its share of constraints it can > become daunting. > In that case, using one letter just hide the mess behind it. > > So while one letter work well for containers and map reduce, and that I > would wish that generic is used in simple way I think it's to early to make > a decision. > Hopefully if the go community doesn't go full Java style with it's generic > one letter could be okay. > > > Le mercredi 20 janvier 2021 à 04:34:05 UTC+1, Ian Lance Taylor a écrit : > >> On Tue, Jan 19, 2021 at 6:33 PM Wojciech S. Czarnecki <oh...@fairbe.org> >> wrote: >> > >> > I'd propose to amend specification so the type parameter identifiers >> were of A-Z set, >> > ie. single uppercase ascii letter. While it is a current convention, it >> would be better >> > to have this convention forced by compiler. First to have an additional >> cue "generics here", >> > second - to close an easy avenue to hide cloudy or malignant constructs >> in the source. >> > >> > = induced by conversation spotted in other thread: >> >> Personally I think this role would be better played by some sort of >> linter. Reasonable people can disagree as to the naming style to use >> for type parameters. >> >> Ian >> >> >> > > Carla Pfaff via golang-nuts" <golan...@googlegroups.com> wrote: >> > >> m8il...@gmail.com wrote: >> > > On Tuesday, 19 January 2021 at 15:39:25 UTC+1 m8il...@gmail.com >> wrote: >> > > >> > > > Seems to me that most generics implementations use a capital letter >> > > > abstracted type syntax that I hate. >> > > >> > > This is just a convention and not part of the syntax, which means >> it's >> > > irrelevant to the discussion about the proposal. You can easily use >> > > lowercase letters/identifiers: >> https://go2goplay.golang.org/p/eWgJSLNTZw8 >> > >> > -- >> > Wojciech S. Czarnecki >> > << ^oo^ >> OHIR-RIPE >> > >> > -- >> > 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...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/20210120033232.7492029f%40xmint. >> >> > -- > 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/9060b24f-810b-451f-bba7-42079c73ca4en%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/9060b24f-810b-451f-bba7-42079c73ca4en%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 on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHQdRsBJ7CVDj5qvsoSwzy8HtqbC0jgVuVT%2B8TKbRFaFw%40mail.gmail.com.
