Re: [go-nuts] Using "er" and "able" for interfaces

[Victor Giordano]

Ouch, i guess that the english grammar is not happy with that comment. 
Commander :D. let's agree that naming is important, you guys also say 
so too. This post  is, 
after all is about naming, so let's try to not criquite the grammar as it 
one the first tool we use to model the world (apart from graphics and 
draws),we may agree on ghaving a better grammar but there is not that the 
case under discussion.

Have you any thoughts about it that could helps embracing the *er 
convention? perphash that would be a more correct question to post here. 
Sorry is i'm beign a little heavy on this, i just like to think and talk.



El jueves, 17 de enero de 2019, 19:40:39 (UTC-3), Rob 'Commander'  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  > wrote:
>
>> On 16 Jan 2019, at 15:42, Victor Giordano > > 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...@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.

Re: [go-nuts] Using "er" and "able" for interfaces

[Victor Giordano]

As far i can see from all the previous answers i summarize this. let's see
at least if we share some points here:

   - The  *er convention is not better or worse than the *able convention,
   the former may apply better in some scenarios than the latter.
   - The "er" suffix goes like a charm with most of the verbs, i guess
  that's why the convention enforces the use on interfaces with a single
  method, because you are able to describe the interface by the sole thing
  that it does.
  - The "er" suffix causes confusion when applied on a subject.
  Stringer, for example, still doesn't have any sense...; this is where the
  purpose of the *er convention gets me dizzy.
  - The "able" suffix works with most of the verbs and subjects alike.
  Recall in java as everthing is an object, the client code is within an
  object, and that object would be the one sending the message to
(or "invoke
  method of") the *able interface. This is part of the "vision" enforced by
  the *able convention, worth to mention in order to understand the intend.
   - The "able" suffix adds indirection (regarding who will perform an
   action), where the "er" is direct (you know who will perform an action),
   my thoughts on this is that each convention allow to see the same
   scenario from a different sides.
  - Example: If i see an abstraction called reader i would expect it to
  have the behaviour to perform reads (over things that are
readable), on the
  other side if see an abstraction called Readable, I would expect
it to have
  the behaviour that allows it be readable (by things that are reader).
  - From what perspective would be correct to approach the scenario? i
  guess there is no predefined answer to this as it is something
specific to
  the business domain and is up to the dev team to decide what is
need to be
  done. Each approach will lead you to different code.

I do believe in honour the language conventions the same as i believe on
doing the things the right way,
V




El sáb., 19 ene. 2019 a las 3:29, Frank Dunn ()
escribió:

> Readable is an adjective as in "This is a readable comment."  Reader is a
> noun as in "Frank is a reader of comments." Read is a verb as in "Read this
> comment."
>
> So what part of speech would interfaces be?  It seems in idiomatic Go they
> would be nouns that can take action. i.e. things that read. Since they are
> defined in terms of functions this makes some sense. Since Frank can read
> he is a reader.
>
> However if they are nouns that can be acted upon i.e. things that can be
> read then using an adjective makes more sense. This comment is readable.
>
> Thoughts?
>
> --
> 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/nzYmUimJUhE/unsubscribe.
> To unsubscribe from this group and all its topics, 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.

Re: [go-nuts] Using "er" and "able" for interfaces

[Robert Engels]

My thought is that this ship has sailed long aGo.

Still, it is interesting how different terminology comes to be. 

> On Jan 18, 2019, at 8:33 PM, Frank Dunn  wrote:
> 
> Readable is an adjective as in "This is a readable comment."  Reader is a 
> noun as in "Frank is a reader of comments." Read is a verb as in "Read this 
> comment." 
> 
> So what part of speech would interfaces be?  It seems in idiomatic Go they 
> would be nouns that can take action. i.e. things that read. Since they are 
> defined in terms of functions this makes some sense. Since Frank can read he 
> is a reader. 
> 
> However if they are nouns that can be acted upon i.e. things that can be read 
> then using an adjective makes more sense. This comment is readable. 
> 
> Thoughts?
> 
> -- 
> 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.

Re: [go-nuts] Using "er" and "able" for interfaces

[Frank Dunn]

Readable is an adjective as in "This is a readable comment."  Reader is a noun 
as in "Frank is a reader of comments." Read is a verb as in "Read this 
comment." 

So what part of speech would interfaces be?  It seems in idiomatic Go they 
would be nouns that can take action. i.e. things that read. Since they are 
defined in terms of functions this makes some sense. Since Frank can read he is 
a reader. 

However if they are nouns that can be acted upon i.e. things that can be read 
then using an adjective makes more sense. This comment is readable. 

Thoughts?

-- 
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.

Re: [go-nuts] Using "er" and "able" for interfaces

[Andy Balholm]

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  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 > > 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 > 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.

Re: [go-nuts] Using "er" and "able" for interfaces

[robert engels]

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  
> 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 > 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.

Re: [go-nuts] Using "er" and "able" for interfaces

[Robert Johnstone]

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  > 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.

Re: [go-nuts] Using "er" and "able" for interfaces

[Ian Davis]

On Thu, 17 Jan 2019, at 7:48 PM, Jakob Borg wrote:
> On 16 Jan 2019, at 15:42, Victor Giordano  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…

I had similar problems at first and I am an native English speaker. I now think 
of it like this: a Reader is something that can Read, just as a Logger is 
something that can Log

All the best,

Ian

-- 
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.

Re: [go-nuts] Using "er" and "able" for interfaces

[Robert Engels]

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  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 () 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  wrote:
 On 16 Jan 2019, at 15:42, Victor Giordano  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.

Re: [go-nuts] Using "er" and "able" for interfaces

[Victor Giordano]

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 () 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  wrote:
>
>> On 16 Jan 2019, at 15:42, Victor Giordano  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.

Re: [go-nuts] Using "er" and "able" for interfaces

[Rob Pike]

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  wrote:

> On 16 Jan 2019, at 15:42, Victor Giordano  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.

Re: [go-nuts] Using "er" and "able" for interfaces

[Jakob Borg]

On 16 Jan 2019, at 15:42, Victor Giordano 
mailto: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.

Re: [go-nuts] Using "er" and "able" for interfaces

[Ian Denhardt]

Quoting Victor Giordano (2019-01-16 12:44:57)

>"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?

Pretty close, but a subtle point is that "-able" makes something the
indirect object, so for example it is not quite right to say that a
"writable" is something that you can ask to do writing -- it is the
thing being written to, whereas the thing doing the writing is a
"writer". In the case of io.Writer either one kindof makes sense, but
the meaning *is* slightly different.

When both are reasonable, -er is generally more idiomatic Go -- but
that's not always the case.

>The Go idiomatic style is to use the '-er' suffix. But this can
>sometimes lead to strange or obscure names even for native English
>speakers.

>For example, an interface with a "Stale() bool" method seems very
>strange when named as "Staler". All these sound weird: Lookuper,
>Errorer, Nexter

The problem with most of these is that the base words aren't verbs; the
-er suffix converts a verb, describing an action, into a noun describing
the thing or person that performs that action -- but "next" isn't an
action, so "nexter" sounds weird.

lookup is a little different -- "I lookup information" scans poorly, and
I'd probably write it as "I look up something" or better yet "I look
something up" -- so that probably has something to do with it, but I
don't know how to describe the rule precisely. Ironically, I often have
an easier time describing grammar rules precisely for German, because
being a native English speaker I didn't learn English grammar in as
structured a way.  :P

-Ian

-- 
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.

Re: [go-nuts] Using "er" and "able" for interfaces

[Victor Giordano]

Thanks you both gentleman for sharing your point of view on this!
I shall assume that the convention doesn't fit in 100% of the cases.

Greetings
V

El miércoles, 16 de enero de 2019, 12:38:22 (UTC-3), Ian Davis escribió:
>
> On Wed, 16 Jan 2019, at 2:42 PM, Victor Giordano 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 is correct.
>
> The Go idiomatic style is to use the '-er' suffix. But this can sometimes 
> lead to strange or obscure names even for native English speakers.
>
> For example, an interface with a "Stale() bool" method seems very strange 
> when named as "Staler". All these sound weird: Lookuper, Errorer, Nexter
>
> My preference is for naming to be clear and understandable as I can make 
> it. I use '-er' if it makes sense, then maybe '-able' or even something 
> that captures something from the domain the usual ones being Logger or 
> DataStore.
>
> All the best,
>
> Ian
>
>
>
>

-- 
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.

Re: [go-nuts] Using "er" and "able" for interfaces

[Ian Davis]

On Wed, 16 Jan 2019, at 2:42 PM, Victor Giordano 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 is correct.

The Go idiomatic style is to use the '-er' suffix. But this can sometimes lead 
to strange or obscure names even for native English speakers.

For example, an interface with a "Stale() bool" method seems very strange when 
named as "Staler". All these sound weird: Lookuper, Errorer, Nexter

My preference is for naming to be clear and understandable as I can make it. I 
use '-er' if it makes sense, then maybe '-able' or even something that captures 
something from the domain the usual ones being Logger or DataStore.

All the best,

Ian


-- 
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.

Re: [go-nuts] Using "er" and "able" for interfaces

[Robert Engels]

Your thinking is correct, but Java has a Reader class as well. I prefer the 
able format, but it depends. You have interfaces like Predicate in Java and not 
Testable. You also have Runnable and not Runner.  In summary - it depends :)

> On Jan 16, 2019, at 8:42 AM, Victor Giordano  wrote:
> 
> Hello all! 
> I don't know very well what is the topic about using "er" or "able" or any 
> other suffix for the single method interfaces (a.k.a. "funcitonal 
> interfaces"), but i would like to address some thoughts, hope you can bear 
> with me, here we go:
> 
> If a take a look to the Readable interface in Java and the io.Reader 
> interface in Golang, i would say the these "two" persons (assuming that they 
> actually were different persons) were thinking in the same thing (i mean, an 
> object to which you can send it a message [or invoke method] to read bytes or 
> chars, let's bear with me here and let's aggree that both interfaces as 
> abstractions has the same intend) but use different naming, right?
> 
> 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?
> 
> I really hope to reach someone who has already thought about this and share 
> the doubts. 
> 
> 
> -- 
> 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.