The -er suffix makes sense when you think of a method invocation as a command, telling an object to do something. This was definitely the model in Smalltalk, where people called them “messages.” In Go, methods are more like functions than in Smalltalk, but some of the idea remains in the naming convention.
Andy > On Jan 18, 2019, at 9:28 AM, robert engels <reng...@ix.netcom.com> wrote: > > Yes, the method should be called read() - the debate is if it should be > Reader or Readable. I prefer the able because it says to me, if something > implements Readable, then any methods defined by Readable I can call - > regardless of the method name. > > It gets more important for interfaces like Partionable, because typically the > methods implemented do not do the partitioning (that would be a Partitioner) > - they instead return the metadata that allows a “Partitioner” to partition > and Partitionable structure. > > To me, this is a better design in most cases - you don’t want the object > doing the actual partitioning. So in Go parlance, the interface would > probably be called PartitionMetaDataProvider. > > > >> On Jan 18, 2019, at 10:43 AM, Robert Johnstone <r.w.johnst...@gmail.com >> <mailto:r.w.johnst...@gmail.com>> wrote: >> >> Hello, >> >> Just to paint the bikeshed... >> >> The -er suffix makes sense for methods that follow the convention of naming >> methods after verbs. Forget io.Reader for a moment, and think of os.File. >> When you call the method Read, you are asking the instance to read from the >> file on disk. myvar.Read can be understood as subject/verb. In this case, >> myvar is the reader, but it is passing the data back to you. >> >> Robert >> >> >> >> On Thursday, 17 January 2019 14:48:30 UTC-5, Jakob Borg wrote: >> On 16 Jan 2019, at 15:42, Victor Giordano <vituc...@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 >> <mailto:golang-nuts+unsubscr...@googlegroups.com>. >> For more options, visit https://groups.google.com/d/optout >> <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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <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.
