Re: [go-nuts] Plurality of package naming

[Nathan Fisher]

struct and class semantics aren't equivalent but they are similar. Which is
why I think the rule "avoid -er" is relevant. If you're struggling to name
something then you probably don't know what it is and what it needs to do.

I'm not advocating going to the Java extreme of fifty syllable names.
Rather I'm siding with the principle that poor names are a smell of they
don't fit or are buckets for random bits of code (eg util).
On Wed, 13 Jul 2016 at 00:26, Thomas Bushnell, BSG 
wrote:

> 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 
> 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  wrote:
>>
>>> On Tue, Jul 12, 2016 at 9:19 AM, Rayland  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.

Re: [go-nuts] Plurality of package naming

['Thomas Bushnell, BSG' via golang-nuts]

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 
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  wrote:
>
>> On Tue, Jul 12, 2016 at 9:19 AM, Rayland  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.

Re: [go-nuts] Plurality of package naming

[Nathan Fisher]

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

> On Tue, Jul 12, 2016 at 9:19 AM, Rayland  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.

Re: [go-nuts] Plurality of package naming

[Sam Whited]

On Tue, Jul 12, 2016 at 9:19 AM, Rayland  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.

Re: [go-nuts] Plurality of package naming

[roger peppe]

I prefer the singular form unless pushed towards the plural for
some reason (for example, because we want both plural and
singular forms).

The plural package names in the stdlib are generally there
because the singular form is a reserved word or
keyword (strings, types, errors, bytes).



On 12 July 2016 at 15:19, Rayland  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.
>
> --
> 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.

[go-nuts] Plurality of package naming

[Rayland]

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.

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