There are *Nullable interfaces in the stdlib. Do what you want - no one will care, sort of. I agree that able is far more readable, and also defacto in other languages. In Go they often do things, because well, it’s Go, and they do things. You just have to get past it. I think the Go designers make these choices to enforce the opinionated nature of the language itself - very communistic in the truth will set you free sort of way. Once you stop fighting these things and get on board it gets easier. It is interesting that when I sit down to write Go, I, as Clint Eastwood would say, “must think in Russian”. Makes it kind of fun.
> On Jan 18, 2019, at 8:09 AM, Victor Giordano <vitucho3...@gmail.com> wrote: > > I shall agree that most natural languages have a grammar far complex than the > required to communicate the important things of life, and would say that > tweaking it a little bit we should not having this thread. But is the nature > of system guided by humans often is not to correct the core problem, instead > to patch it :P. So... leaving chat aside... going to the matter: > > The thing that makes wonder: is that the "able" convention already works for > me, instead with the "er" convention i get the feeling that is more difficult > to employ it on 100% of the times (you know, it was kind of hard to read > "Stringer" as a meaningful name on my early days on golang, i would rather > thing that "Stringer" is the object that "strings" things, instead of > something that can be transformed into a char sequence) So the question i > made to myself is, why use another convention is out there? if there is > already one that works, in terms to be more "universally" readable. I guess > we all agree that naming is trully important and often is relative to the > observer. That is why i try to feel that using "able" or "er" is a question > of perspective, i mean, how do you see the actors in the system. "able" > passive, "er" active (as i stated on the first mail of this thread) > > Very important disclaimer: I do not try to be hard on the guideline, instead > i try to adhere as a good citizen of a community of practices. I may have to > reflect that after many years in java, perhaps my mind gets a little fixed to > use "able"... i mean, we are beigns of habits, so it could happen to me > implying that i may need a mind mender, i'm totally mendable by the way :P. > > Or perhaps the right approach it to embrace both conventions and employ them > according to convenience. (:+1:) > > Greetings > V > > > > > > > > > > >> El jue., 17 ene. 2019 a las 19:40, Rob Pike (<r...@golang.org>) escribió: >> It depends on the nature of the verb (method) and whether it's being used to >> refer to the subject or the object, whether it is transitive or >> intransitive, and all the rest of that messy human grammar nonsense. Which >> is why trying to align the with justifications to English grammar is a >> fool's errand. Instead we make it a Go-specific recommendation, informed by >> not bound by English rules. >> >> Guidelines, not hard rules. io.Reader is not a English word. >> >> -rob >> >> >>> On Fri, Jan 18, 2019 at 6:48 AM Jakob Borg <ja...@kastelo.net> wrote: >>>> On 16 Jan 2019, at 15:42, Victor Giordano <vitucho3...@gmail.com> wrote: >>>> >>>> As far i can get to understand the english language (i'm not a native >>>> speaker), the "er" seems to denotes or describe things in a more "active >>>> way" (the thing that they actually do by itself), and the "able" describes >>>> things in a more "passive way" (the thing that you can "ask it/his/her" >>>> to do). Do you find this appreciation correct? >>> >>> This was a mental stumbling block for me for a long time when I started out >>> with Go. For me, the "Reader" is the one who calls Read(), so an io.Reader >>> seemed like the opposite of what I wanted. I would have better understood >>> it as io.Readee. It works out better if I see the Reader as some sort of >>> intermediate entity that affects reads on whatever the underlying thing is >>> you want to read from… Or if I see it as just an interface-indicating >>> nonsense suffix, like a capital-I prefix… >>> >>> //jb >>> -- >>> 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. > > -- > 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. -- 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.
