On Sun, Jun 27, 2021 at 8:17 PM Victor Giordano <vitucho3...@gmail.com> wrote:
> 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>. > Yes, I'm aware this works. That wasn't in doubt. The question is "is it better". In my opinion, it isn't. > 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/CAEkBMfFGzV1YEipYRgTNZxsNdNasd5a9vVHxysgEh6%3DNgZQ%2BTA%40mail.gmail.com.
