On Thu, Sep 2, 2021 at 12:26 PM Markus Heukelom <markus.heuke...@gain.pro> wrote:
> So, turns out, the function is actually listed under the type "Handler", > probably because it implements that interface. > Because it returns that type. It's a heuristic to find "constructors" of types, which is useful if you know you want that type and want to know how to get one. That's helpful indeed if you are interested to see which types implement > "Handler" (even though the index does not state that "Handler" is an > interface so you first wonder 1 minute why "Handler" has types hanging > under it instead of methods, but ok). > To be clear, a function doesn't "implement" an interface. Only types do. And there is no association (neither in the language, nor the docs) between a type and the interfaces it implements. The association between the type and its constructors is, however, independent of whether that type is an interface or a concrete type. However, the *primary* use of the index is to *quickly* find that function > you're looking for. That's what indexes are for. > I don't agree with the premise that "I want to find the function" is inherently more useful than "I want to see how to get this type". I also wouldn't claim it's *less* useful. Both are very useful, depending on what you want. Personally, if I already know what function I'm looking for, I use Ctrl+F and my browsers search function instead. And I find it far more often useful to be able to quickly see how I'm intended to construct a certain type (without knowing the name of the function to do so). > > Another example is the x/net/html package. > > The "Parse" function is arguably the most important function of the whole > package. Well - you can only find Parse *under* the Node type, which is by > default collapsed. > > Another fun example is the documentation for type http.FileSystem. It > contains this text: > > "See the FileServer function to convert a FileSystem to a Handler." > > Awesome! Let's look up that FileServer function in the index. > > Well. It's not there. > > No. > > You are expected to be so smart to realise that FileServer of course > implements the Handler interface and is therefore only listed under the > collapsed Handler type. Maddening. > > Proposal: just list all functions in the index please. > > NOTE: I admire Go & Go.dev. My exaggerative style is just used to > illustrate my point. > > NOTE: My apologies if this is not the place for go.dev feedback. Please > redirect me. > > NOTE: I know that the index in the old package docs also has this > structure. It has somewhat the same issue, but at least you could scroll > through it a scan for function names. > > > > > > > > > > -- > 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/15cb6bbd-83fc-44f7-a5fc-a922b7112461n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/15cb6bbd-83fc-44f7-a5fc-a922b7112461n%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/CAEkBMfHnhKmva19Bf1z%2BEiBzJ5aEoE_ibeuBsrShhQmGzxpb%2Bw%40mail.gmail.com.
