Using "er" and "able" for interfaces

[Victor Giordano]

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. 

[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 :)

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

[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

[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

[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

[Roberto Zanotto]

Java is object-oriented, Go is subject-oriented :)

[Jakob Borg]

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

[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

--

[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

 

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

[Haddock]

Am Mittwoch, 16. Januar 2019 15:42:38 UTC+1 schrieb Victor Giordano:

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

The approach with "er" in Go (Stringer, etc.)  seems to me to be the result of a function-oriented attitude (function = procedure, not functional programming) whereas in Java an object-oriented attitude is applied where classes and interface are nouns (because classes and interfaces define functions they contain, but they are not standalone functions.

In Go, unlike Java, you can define free functions, e.g. methods that are not defined inside some container like a class or a module. This is a general attitude in system programming to use member functions as well as free functions. I don't know why since I'm application developer with too little experience in system programming. You can also see this when looking at programming languages that are geared towards system programming like D, Rust, C++.

So when you define an interface for something that in the end will be backed by a single free function, rather than a collection of functions, it leads to a naming style with "er" which denotes a verb rather than a nound.

[Ian Davis]

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

[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

[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 <r.w.jo...@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

[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

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

[Robert Engels]

My thought is that this ship has sailed long aGo.

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

[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

--
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...@googlegroups.com.

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