That's advice for a very different style of language than Go.

Go does not have "objects" in the sense of that post. A Go interface, for
example, does not "have lots of instance variables, lots of arguments, and
pass lots of data around probably."

A class is not a struct is not a Go interface.

Thomas

On Tue, Jul 12, 2016 at 4:23 PM Nathan Fisher <nfis...@junctionbox.ca>
wrote:

> There's a good oop blog article on the caveats of naming classes (struct)
> ending in -er.
>
> http://objology.blogspot.co.uk/2011/09/one-of-best-bits-of-programming-advice.html?m=1
>
> I know the reader/writer interface kind of flies in the face of this but I
> think that's partly associated with it being an interface and its focus on
> one method.
>
> Personally if it's RESTy I'd opt for BlahResource where Blah is the
> resource that it manages which will probably map to an underlying
> serialisable struct with additional REST elements (eg next, self, etc).
>
> On Tue, 12 Jul 2016 at 17:41, Sam Whited <s...@samwhited.com> wrote:
>
>> On Tue, Jul 12, 2016 at 9:19 AM, Rayland <guianul...@gmail.com> wrote:
>> > When does it make sense for a package to be named in plural? For
>> example,
>> > I'm currently working on a MVC framework and for me it makes sense to
>> have a
>> > "controller" package as opposed to "controllers", but I saw that Beego
>> > prefers plural for the same case.
>>
>> Generally speaking, try to consider how your users will write things
>> that use your package and not what's actually in it. For instance,
>> which makes the better API:
>>
>>     controller.New()
>>
>> or:
>>
>>     controllers.NewController()
>>
>> The second is redundant, so I'd argue that the first one will look
>> better in your users code. However, given the example:
>>
>>     byte.Split(b []byte)
>>
>> vs.
>>
>>     bytes.Split(b []byte)
>>
>> the second may be more expected because you're operating on a collection.
>>
>> Of course, both of these are just my opinion, but it's just to
>> illustrate how I generally think about picking a name. Instead of
>> "what will my code in the package look like" think "what will my users
>> write using this package?"
>>
>> —Sam
>>
>> --
>> 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.

Reply via email to