Axel, thanks for the insight! You give a lot to think about and that is what was looking for. The path example is very nice btw!. Is like working with a raw data value that needs a little bit validation to ensure it correctines. Like having a type for natural numbers (like 'Natural') that can be created with a method FromInt(x int) error and you validate in it that the x is actually a positive integer. Life is nice when we employ types that lead to more robust code.
I do get `http.HandlerFunc` means something "bigger" than `func(ResponseWriter, *Request)` because the type comes "augmented" with another method for calling the function with another name thus becoming compliant with the type Handler interface. That is indeed an understandable reason. But but but... just bear with me... cuz, in this specific case, I guess you could employ both "approaches". See my example here <https://play.golang.org/p/f2NOTHjffCm>. Also I feel the need to clarify something about I stated... > Thanks to all for the answer, i really try to see any actual reason but i still don't get it. For me, to my humble acknowledgement, if I define a type I tend to use everywhere it appears. Period. End of the story. I have to admit, although I follow this recipe as a compass, I may pass by sometimes and leave redundant definitions. It is okay, after all, we are humans and errors happen. El dom, 27 jun 2021 a las 13:28, Axel Wagner (<axel.wagner...@googlemail.com>) escribió: > On Sun, Jun 27, 2021 at 6:05 PM Victor Giordano <vitucho3...@gmail.com> > wrote: > >> Thanks to all for the answer, i really try to see any actual reason but i >> still don't get it. For me, to my humble acknowledgement, if I define a >> type I tend to use everywhere it appears. Period. End of the story. >> > >> > FWIW, arguing that `http.HandleFunc` should take a `http.HandlerFunc` >> because there exists a defined type with the same underlying type as the >> parameter is a bit like arguing every function that takes an `int64` should >> instead take a time.Duration <https://golang.org/pkg/time/#Duration>. >> >> Allow me to put in different words: if you define `func >> doSomething(duration int64)` at least i will argue why don't employ >> time.Duration <https://golang.org/pkg/time/#Duration> as a type there, >> if the parameter actually represents a Duration that is also a defined >> type, ¿you don't?. >> > > Yes. But that's the thing - if what the function actually takes a > duration, then the correct type is a duration. But the type > `http.HandleFunc` takes is *not* a `http.HandlerFunc`, it's a > `func(http.ResponseWriter, *http.Request)`. It's a different type and it's > the correct type to describe what that function is for. If the type was > `http.HandlerFunc`, then `http.HandleFunc` wouldn't need to exist, because > `http.Handle` would suffice. > > For example, if you had a function > > // DurationFromMS returns a time.Duration, based on a duration given as an > integer in ms. > func DurationFromMS(d int64) time.Duration { > return time.Duration(d * 1000) > } > > Would you make the parameter type `time.Duration`? After all, it > represents a duration, right? But you wouldn't. It would be the wrong type > to represent what the function does. > > Or, a different example: We could introduce a new type in the `filepath` > package: > > // Path is a path, using the OS-specific delimiter > type Path string > > // Verify makes sure that p is a path, using the correct, OS-specific > delimiter. > // It returns p as a Path, and an error, if p was invalid. > func Verify(p string) (Path, error) > > We could then have `filepath.Join` etc. take `Path`s, instead of > `string`s, to represent that the argument actually must be a valid path, > using the OS-specific separator. Which would be different from `path.Path`, > of course, which would always use "/" as a separator. Meaning you wouldn't > be able to accidentally use one as the other, which would add type-safety. > > But should `Verify` take a `Path` here? Of course not. That would be the > wrong type. It just returns its argument converted into the correct type, > but semantically, it still takes *a plain string*. Before you pass the path > into `Verify`, it doesn't have the semantic association of "this string is > an OS-specific path" - that's exactly the semantic association that > `Verify` creates. > > Your argument hinges on the assumption that `http.HandleFunc`s parameter > has the semantic interpretation (not only the same underlying type as) as > `http.HandlerFunc`. But it doesn't. The semantic interpretation of the > argument to `http.HandleFunc` is a plain function. Otherwise, it wouldn't > need to exist - because we already *have* a function that can take a > `http.HandlerFunc`: `http.Handle`. > > The plain func is describing *exactly* the type that function should > take. `http.HandlerFunc` would be the wrong type. > > >> I won't say the same about other things that hold an int64 that >> represents for example an ID of record in a database. >> >> >> >> El dom, 27 jun 2021 a las 12:56, 'Axel Wagner' via golang-nuts (< >> golang-nuts@googlegroups.com>) escribió: >> >>> FWIW, arguing that `http.HandleFunc` should take a `http.HandlerFunc` >>> because there exists a defined type with the same underlying type as the >>> parameter is a bit like arguing every function that takes an `int64` should >>> instead take a time.Duration <https://golang.org/pkg/time/#Duration>. >>> That's just not how types tend to work. >>> >>> It makes no sense for `http.HandleFunc` to take a `http.HandlerFunc`, >>> because it's purpose is specifically to work on a plain function. If you >>> have an `http.HandlerFunc`, you can already just call `http.Handle` - there >>> is no need to make a separate function that takes a *specific* >>> implementation of `http.Handler`. >>> >>> On Sun, Jun 27, 2021 at 5:51 PM Axel Wagner < >>> axel.wagner...@googlemail.com> wrote: >>> >>>> On Sun, Jun 27, 2021 at 5:25 PM Victor Giordano <vitucho3...@gmail.com> >>>> wrote: >>>> >>>>> I keep wondering if they code that way for any reason. With "code that >>>>> way" I mean: define a type and then not use it. >>>>> >>>> >>>> As I said: It's used plenty of times. Both inside of `net/http` and >>>> outside of it. >>>> >>>>> >>>>> - So, ¿why not employ the type defined in the first place? >>>>> >>>>> I feel like I gave a bunch of reasons for this too. >>>> >>>> >>>>> Don't get me wrong,but if I define a type I tend to use that type >>>>> where it appears. That is in fact the basis of making types, to use them. >>>>> So that feeds my questioning! >>>>> >>>>> >>>>> El dom, 27 jun 2021 a las 11:46, 'Axel Wagner' via golang-nuts (< >>>>> golang-nuts@googlegroups.com>) escribió: >>>>> >>>>>> If I understand you correctly, you are suggesting to replace the >>>>>> parameter type `func(http.ResponseWriter, *http.Request)` with the >>>>>> parameter type `http.HandlerFunc`. You've been (correctly) told that we >>>>>> can't make that change, because it would break the Go 1 compatibility >>>>>> change (as there is code which currently compiles which wouldn't compile >>>>>> after that change). But you are wondering if, *ignoring* the >>>>>> compatibility >>>>>> guarantee, it would be a good change. Am I getting this right? >>>>>> >>>>>> If so: I don't think it would be a good change. >>>>>> >>>>>> First, it's important to realize that the *only* reason, >>>>>> `http.HandlerFunc` exists at all, is so that you can write a >>>>>> `func(http.ResponseWriter, *http.Request)` and use it as a >>>>>> `http.Handler`, >>>>>> in the places where `net/http` expects the latter. You say the type isn't >>>>>> used - but it is. It's used by *users* of the `net/http` package, to make >>>>>> their plain functions into `http.Handler`s. It is also used in `net/http` >>>>>> itself - in the exact function you are referring to >>>>>> <https://golang.org/src/net/http/server.go?s=77627:77714#L2487>. >>>>>> That is the exact and only purpose of that type, to make a plain function >>>>>> implement the `Handler` interface. So, taking a plain function as a >>>>>> parameter *is the purpose of having the `HandlerFunc` type*. >>>>>> >>>>>> You also say that adding types is a good thing. I tend to disagree >>>>>> with that as a general statement. Adding types is a good thing, if it >>>>>> serves as important documentation or if it serves to catch bugs. I don't >>>>>> think either of these would be happening with this change. In terms of >>>>>> documentation - well, you don't *have* to pass a `http.HandlerFunc`, so >>>>>> there is no reason for the documentation to make it clear that you >>>>>> should. >>>>>> You can (and should) just pass a plain `func`. So, using the defined type >>>>>> here wouldn't serve as documentation, it would document the *wrong* >>>>>> thing. >>>>>> >>>>>> As for catching bugs: Making the parameter type a defined type would >>>>>> only change one thing in terms of type-safety. It would mean that if you >>>>>> define a *different* type `type MyFunc func(http.ResponseWriter, >>>>>> *http.Request)`, the compiler would prevent you from writing >>>>>> `http.HandleFunc(…, MyFunc(f))`. Preventing a bug would thus require that >>>>>> your `MyFunc` type would have to be used semantically differently from >>>>>> `http.HandlerFunc`. But that seems *exceedingly* unlikely, given that you >>>>>> defined `MyFunc` in terms of the `net/http` package. And it would then >>>>>> appear *exceedingly* unlikely, that you'd accidentally mix the two up - >>>>>> almost all usages of `http.HandleFunc` will pass the name of some defined >>>>>> function and that will always work. >>>>>> >>>>>> But all of this discussion is really moot. It's a breaking change, so >>>>>> it can't happen - whether it's a good change or not doesn't exactly >>>>>> matter >>>>>> at that point. Personally, *if* we could "go back in time" and wouldn't >>>>>> have to worry about backwards compatibility, my vote would rather be to >>>>>> change >>>>>> the language to make the HandlerFunc type obsolete >>>>>> <https://github.com/golang/go/issues/21670> and remove it altogether. >>>>>> >>>>>> On Sun, Jun 27, 2021 at 3:53 PM Victor Giordano < >>>>>> vitucho3...@gmail.com> wrote: >>>>>> >>>>>>> Hello gophers! >>>>>>> >>>>>>> While studing at this source code >>>>>>> <https://github.com/golang/go/blob/37f9a8f69d6299783eac8848d87e27eb563500ac/src/net/http/server.go> >>>>>>> in search for some knowledge and enlightment, i do note that in some >>>>>>> file a >>>>>>> type is defined and then is not used in a place where it could be used. >>>>>>> This open an interrogant for me, because tipification is often good >>>>>>> thing, >>>>>>> regardless the language I may state, and I express it via a >>>>>>> ticket <https://github.com/golang/go/issues/46926>. I get the idea >>>>>>> that due to language grammar changing the code would be a breaking >>>>>>> change. >>>>>>> >>>>>>> But i keep wondering if they actually do this for a reason.. i mean, >>>>>>> given the possiblity to get back in time, ¿does the team at golang will >>>>>>> write the same source code, definiting a type with a name and then >>>>>>> intenttionally not using it? i mean...i keep wondering if there is any >>>>>>> reason for defined types and then not use it and using the gitlab >>>>>>> channel i >>>>>>> probably fail to express my initial intention. I do often read some >>>>>>> third >>>>>>> party code, in order to view others minds (or try at least..), what i'm >>>>>>> asking here is a question in order to get another people point of view. >>>>>>> >>>>>>> Thanks again! >>>>>>> >>>>>>> -- >>>>>>> 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/96369719-6200-4765-aee1-83befce04666n%40googlegroups.com >>>>>>> <https://groups.google.com/d/msgid/golang-nuts/96369719-6200-4765-aee1-83befce04666n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to a topic in >>>>>> the Google Groups "golang-nuts" group. >>>>>> To unsubscribe from this topic, visit >>>>>> https://groups.google.com/d/topic/golang-nuts/VBQrlI6-zW0/unsubscribe >>>>>> . >>>>>> To unsubscribe from this group and all its topics, 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/CAEkBMfHnCTf_4G5ZhGX0EXBKJRN9LcEWbKWOdPiCTKdX6SDqPA%40mail.gmail.com >>>>>> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHnCTf_4G5ZhGX0EXBKJRN9LcEWbKWOdPiCTKdX6SDqPA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> >>>>> >>>>> -- >>>>> V >>>>> >>>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "golang-nuts" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/golang-nuts/VBQrlI6-zW0/unsubscribe. >>> To unsubscribe from this group and all its topics, 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/CAEkBMfHiQP0WEbGPrFkY5gSzaaiQ5OqisySiy8_yUdfVAE-v6w%40mail.gmail.com >>> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHiQP0WEbGPrFkY5gSzaaiQ5OqisySiy8_yUdfVAE-v6w%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> V >> > -- V -- 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/CAPUu9stqHd5kY_1LuDPy%3DPALaxCAXJp1GB%2BCiuW%2BUTN%3D0mE9Kg%40mail.gmail.com.
