Re: [go-nuts] Package Stutter

[Burak Serdar]

On Mon, Dec 3, 2018 at 4:25 PM Robert Engels  wrote:
>
> Btw, I am working on some issues/proposals/tools that I think will help the 
> situation - not just complaining.

I'd like to hear more about what you're planning to do.

>
> > On Dec 3, 2018, at 5:19 PM, Robert Engels  wrote:
> >
> > Probably another thread unto itself, and some of the issues have already 
> > been corrected like the addition of modules.
> >
> > One of the biggest is dynamic code changes at runtime, while debugging, a 
> > lot of web apis, etc.  Often there’s a lot of steps to get to X in an 
> > enterprise app. It’s a much slower cycle


We just released a set of customer-facing web services, implemented in
go. It was much faster to get to X compared to other such projects I
was involved with before when I did the same thing in Java. And we did
this with a team of developers with backgrounds in Java and Ruby. I
believe Go is a very good replacement for other enterprise-y languages
with much lower overhead. That doesn't mean it can't be improved, but
I think it is already a significant improvement.

.
> >
> > Another is probably the debugging itself. Even the smallest app that uses 
> > gRPC as an example creates dozens of Go routines, and these routines are 
> > “named” only by their top level stack method, it’s a nightmare debugging a 
> > highly concurrent app.


That is difficult regardless of the language.

> >
> > There’s a lot more, but I really don’t want to stir the hornets nest at 
> > this point, the community has exhausted me a bit...
> >
> >>> On Dec 3, 2018, at 3:46 PM, Burak Serdar  wrote:
> >>>
> >>> On Sun, Dec 2, 2018 at 11:09 PM Robert Engels  
> >>> wrote:
> >>>
> >>> I agree that is an important consideration, but it seems less important 
> >>> if the packages are small and focused.
> >>>
> >>> I think an important point to consider is that there are systems apps, 
> >>> and enterprise apps. These rules seem well suited to systems apps, but 
> >>> maybe not so well suited to business enterprise apps.
> >>>
> >>> As I become more familiar with Go I become more convinced that is great 
> >>> for systems apps, and not very workable for business apps. I’m trying to 
> >>> work on some things that might change the latter, but to get there I’m 
> >>> trying to fully understand the thinking behind these design decisions.
> >>
> >> Can you elaborate on this a bit?  Why do you think the two are different?
> >>
> >> I've been using Go to write "enterprise" apps for a while, and the
> >> process has been much easier than it used to be with Java. This was
> >> something we accepted from the get-go without much questioning, it is
> >> mildly irritating to some, but not a big deal. What mattered was the
> >> amount of boilerplate code, readability, learning curve, clarity of
> >> code, etc.
> >>
> >>>
> > On Dec 2, 2018, at 10:56 PM, Ian Lance Taylor  wrote:
> >
> > On Sat, Dec 1, 2018 at 7:25 PM Robert Engels  
> > wrote:
> >
> > The way to fix it though it just to use dot imports, and encourage it! 
> > The only time dot imports don’t work is when there isn’t package 
> > stutter. Seems like a no brainer and you get the best of both worlds.
> 
>  Go programs that do not use dot imports have the convenient feature
>  that any unqualified name must be defined somewhere in the same
>  package.  The first component of any qualified name must be either
>  defined in the same package or be the name of a package imported in
>  the same file.  These convenient facts make it easier to read Go code
>  and quickly understand where each name is coming from.
> 
>  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.
> >>
> >> --
> >> 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] Package Stutter

[Robert Engels]

Btw, I am working on some issues/proposals/tools that I think will help the 
situation - not just complaining. 

> On Dec 3, 2018, at 5:19 PM, Robert Engels  wrote:
> 
> Probably another thread unto itself, and some of the issues have already been 
> corrected like the addition of modules. 
> 
> One of the biggest is dynamic code changes at runtime, while debugging, a lot 
> of web apis, etc.  Often there’s a lot of steps to get to X in an enterprise 
> app. It’s a much slower cycle.
> 
> Another is probably the debugging itself. Even the smallest app that uses 
> gRPC as an example creates dozens of Go routines, and these routines are 
> “named” only by their top level stack method, it’s a nightmare debugging a 
> highly concurrent app. 
> 
> There’s a lot more, but I really don’t want to stir the hornets nest at this 
> point, the community has exhausted me a bit...
> 
>>> On Dec 3, 2018, at 3:46 PM, Burak Serdar  wrote:
>>> 
>>> On Sun, Dec 2, 2018 at 11:09 PM Robert Engels  wrote:
>>> 
>>> I agree that is an important consideration, but it seems less important if 
>>> the packages are small and focused.
>>> 
>>> I think an important point to consider is that there are systems apps, and 
>>> enterprise apps. These rules seem well suited to systems apps, but maybe 
>>> not so well suited to business enterprise apps.
>>> 
>>> As I become more familiar with Go I become more convinced that is great for 
>>> systems apps, and not very workable for business apps. I’m trying to work 
>>> on some things that might change the latter, but to get there I’m trying to 
>>> fully understand the thinking behind these design decisions.
>> 
>> Can you elaborate on this a bit?  Why do you think the two are different?
>> 
>> I've been using Go to write "enterprise" apps for a while, and the
>> process has been much easier than it used to be with Java. This was
>> something we accepted from the get-go without much questioning, it is
>> mildly irritating to some, but not a big deal. What mattered was the
>> amount of boilerplate code, readability, learning curve, clarity of
>> code, etc.
>> 
>>> 
> On Dec 2, 2018, at 10:56 PM, Ian Lance Taylor  wrote:
> 
> On Sat, Dec 1, 2018 at 7:25 PM Robert Engels  
> wrote:
> 
> The way to fix it though it just to use dot imports, and encourage it! 
> The only time dot imports don’t work is when there isn’t package stutter. 
> Seems like a no brainer and you get the best of both worlds.
 
 Go programs that do not use dot imports have the convenient feature
 that any unqualified name must be defined somewhere in the same
 package.  The first component of any qualified name must be either
 defined in the same package or be the name of a package imported in
 the same file.  These convenient facts make it easier to read Go code
 and quickly understand where each name is coming from.
 
 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.
>> 
>> -- 
>> 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] Package Stutter

[Robert Engels]

Probably another thread unto itself, and some of the issues have already been 
corrected like the addition of modules. 

One of the biggest is dynamic code changes at runtime, while debugging, a lot 
of web apis, etc.  Often there’s a lot of steps to get to X in an enterprise 
app. It’s a much slower cycle.

Another is probably the debugging itself. Even the smallest app that uses gRPC 
as an example creates dozens of Go routines, and these routines are “named” 
only by their top level stack method, it’s a nightmare debugging a highly 
concurrent app. 

There’s a lot more, but I really don’t want to stir the hornets nest at this 
point, the community has exhausted me a bit...

> On Dec 3, 2018, at 3:46 PM, Burak Serdar  wrote:
> 
>> On Sun, Dec 2, 2018 at 11:09 PM Robert Engels  wrote:
>> 
>> I agree that is an important consideration, but it seems less important if 
>> the packages are small and focused.
>> 
>> I think an important point to consider is that there are systems apps, and 
>> enterprise apps. These rules seem well suited to systems apps, but maybe not 
>> so well suited to business enterprise apps.
>> 
>> As I become more familiar with Go I become more convinced that is great for 
>> systems apps, and not very workable for business apps. I’m trying to work on 
>> some things that might change the latter, but to get there I’m trying to 
>> fully understand the thinking behind these design decisions.
> 
> Can you elaborate on this a bit?  Why do you think the two are different?
> 
> I've been using Go to write "enterprise" apps for a while, and the
> process has been much easier than it used to be with Java. This was
> something we accepted from the get-go without much questioning, it is
> mildly irritating to some, but not a big deal. What mattered was the
> amount of boilerplate code, readability, learning curve, clarity of
> code, etc.
> 
>> 
 On Dec 2, 2018, at 10:56 PM, Ian Lance Taylor  wrote:
 
 On Sat, Dec 1, 2018 at 7:25 PM Robert Engels  wrote:
 
 The way to fix it though it just to use dot imports, and encourage it! The 
 only time dot imports don’t work is when there isn’t package stutter. 
 Seems like a no brainer and you get the best of both worlds.
>>> 
>>> Go programs that do not use dot imports have the convenient feature
>>> that any unqualified name must be defined somewhere in the same
>>> package.  The first component of any qualified name must be either
>>> defined in the same package or be the name of a package imported in
>>> the same file.  These convenient facts make it easier to read Go code
>>> and quickly understand where each name is coming from.
>>> 
>>> 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.
> 
> -- 
> 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] Package Stutter

[Burak Serdar]

On Sun, Dec 2, 2018 at 11:09 PM Robert Engels  wrote:
>
> I agree that is an important consideration, but it seems less important if 
> the packages are small and focused.
>
> I think an important point to consider is that there are systems apps, and 
> enterprise apps. These rules seem well suited to systems apps, but maybe not 
> so well suited to business enterprise apps.
>
> As I become more familiar with Go I become more convinced that is great for 
> systems apps, and not very workable for business apps. I’m trying to work on 
> some things that might change the latter, but to get there I’m trying to 
> fully understand the thinking behind these design decisions.

Can you elaborate on this a bit?  Why do you think the two are different?

I've been using Go to write "enterprise" apps for a while, and the
process has been much easier than it used to be with Java. This was
something we accepted from the get-go without much questioning, it is
mildly irritating to some, but not a big deal. What mattered was the
amount of boilerplate code, readability, learning curve, clarity of
code, etc.

>
> > On Dec 2, 2018, at 10:56 PM, Ian Lance Taylor  wrote:
> >
> >> On Sat, Dec 1, 2018 at 7:25 PM Robert Engels  wrote:
> >>
> >> The way to fix it though it just to use dot imports, and encourage it! The 
> >> only time dot imports don’t work is when there isn’t package stutter. 
> >> Seems like a no brainer and you get the best of both worlds.
> >
> > Go programs that do not use dot imports have the convenient feature
> > that any unqualified name must be defined somewhere in the same
> > package.  The first component of any qualified name must be either
> > defined in the same package or be the name of a package imported in
> > the same file.  These convenient facts make it easier to read Go code
> > and quickly understand where each name is coming from.
> >
> > 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.

-- 
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] Package Stutter

[Robert Engels]

I don’t think that’s an issue. You only have references to both Employee in the 
integration code, and that should probably always use fully qualified names - 
if I’m understanding your concerns, but I’m not sure I am. 

> On Dec 3, 2018, at 10:23 AM, Bakul Shah  wrote:
> 
> 
> 
>> On Dec 3, 2018, at 8:08 AM, Robert Engels  wrote:
>> 
>> I understand that, and when working in code that uses both types, which is 
>> probably limited, you fully qualify. This is pretty standard stuff in the 
>> enterprise world, as well architected solutions are segmented, so you only 
>> encounter this problem at the integration points, and that code is qualified.
> 
> If you import another package where you are already using a dot import,
> you are already using Employee. You then decide to change the new import
> to dot import, at which point you discover the name clash. Now you have
> to qualify all existing Employee references with the first package. So
> a new import forces you to edit code that may have nothing to do with the
> new import.
> 
> If you don't do this, you will have Employee references (to the first pkg)
> that are not qualified and some qualified ones. This will confuse things
> because someone (or you, a few months later) will then go looking for
> the Employee defn in your own package and not find it.
> 
> It can all be made to work but why complicate things when a simple rule
> suffices?
> 
>> 
>> You have a similar problem if both applications have a model package. Now 
>> you need to override the import on one of them. No difference IMO. 
>> 
 On Dec 3, 2018, at 10:03 AM, Bakul Shah  wrote:
 
 On Dec 3, 2018, at 6:52 AM, Robert Engels  wrote:
 
 I think people are misunderstanding my equal footing need. I don’t mean 
 for all applications, I mean for a application. 
 
 Here’s another example. You have a enterprise payroll application. You 
 have a model package. You have model.Employee. Having to use 
 model.Employee throughout the application is noise. Everyone working on 
 the application knows that Employee means model.Employee. It is part of 
 the language (dsl in a way) for that application. 
>>> 
>>> Now suppose you have to write a application that
>>> has to access payroll as well as employee performance
>>> review, health insurance, expense reporting, connect
>>> to 3rd parties for special discounts for various things,
>>> etc. Each of these subsystems may have their own
>>> definition of Employee (which may be stored in their
>>> own databases). This list may grow over time and you
>>> don't want to have to recompile and retest *existing*
>>> packages by changing some central Employee type.
>> 
> 
> -- 
> 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] Package Stutter

[Tristan Colgate]

Whilst not exaclty the peek of modern tooling, grep is one method of
checking where and how your package is used. That's a lot clearer without
dot imports.
  I've never used a dot import, and don't think I have seen one in the
wild. Allowing dot imports feels like a bit of a wart (but one that is
easily, and widely, avoided).
  FWIW, I definitely did not feel that was on day 1 of my Go journey. All
those package names looked annoying. I can't say when it stopped being
annoying, but it didn't take long at all.

On Mon, 3 Dec 2018 at 16:23 Bakul Shah  wrote:

>
>
> > On Dec 3, 2018, at 8:08 AM, Robert Engels  wrote:
> >
> > I understand that, and when working in code that uses both types, which
> is probably limited, you fully qualify. This is pretty standard stuff in
> the enterprise world, as well architected solutions are segmented, so you
> only encounter this problem at the integration points, and that code is
> qualified.
>
> If you import another package where you are already using a dot import,
> you are already using Employee. You then decide to change the new import
> to dot import, at which point you discover the name clash. Now you have
> to qualify all existing Employee references with the first package. So
> a new import forces you to edit code that may have nothing to do with the
> new import.
>
> If you don't do this, you will have Employee references (to the first pkg)
> that are not qualified and some qualified ones. This will confuse things
> because someone (or you, a few months later) will then go looking for
> the Employee defn in your own package and not find it.
>
> It can all be made to work but why complicate things when a simple rule
> suffices?
>
> >
> > You have a similar problem if both applications have a model package.
> Now you need to override the import on one of them. No difference IMO.
> >
> >> On Dec 3, 2018, at 10:03 AM, Bakul Shah  wrote:
> >>
> >>> On Dec 3, 2018, at 6:52 AM, Robert Engels 
> wrote:
> >>>
> >>> I think people are misunderstanding my equal footing need. I don’t
> mean for all applications, I mean for a application.
> >>>
> >>> Here’s another example. You have a enterprise payroll application. You
> have a model package. You have model.Employee. Having to use model.Employee
> throughout the application is noise. Everyone working on the application
> knows that Employee means model.Employee. It is part of the language (dsl
> in a way) for that application.
> >>
> >> Now suppose you have to write a application that
> >> has to access payroll as well as employee performance
> >> review, health insurance, expense reporting, connect
> >> to 3rd parties for special discounts for various things,
> >> etc. Each of these subsystems may have their own
> >> definition of Employee (which may be stored in their
> >> own databases). This list may grow over time and you
> >> don't want to have to recompile and retest *existing*
> >> packages by changing some central Employee type.
> >
>
> --
> 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] Package Stutter

[Bakul Shah]

> On Dec 3, 2018, at 8:08 AM, Robert Engels  wrote:
> 
> I understand that, and when working in code that uses both types, which is 
> probably limited, you fully qualify. This is pretty standard stuff in the 
> enterprise world, as well architected solutions are segmented, so you only 
> encounter this problem at the integration points, and that code is qualified.

If you import another package where you are already using a dot import,
you are already using Employee. You then decide to change the new import
to dot import, at which point you discover the name clash. Now you have
to qualify all existing Employee references with the first package. So
a new import forces you to edit code that may have nothing to do with the
new import.

If you don't do this, you will have Employee references (to the first pkg)
that are not qualified and some qualified ones. This will confuse things
because someone (or you, a few months later) will then go looking for
the Employee defn in your own package and not find it.

It can all be made to work but why complicate things when a simple rule
suffices?

> 
> You have a similar problem if both applications have a model package. Now you 
> need to override the import on one of them. No difference IMO. 
> 
>> On Dec 3, 2018, at 10:03 AM, Bakul Shah  wrote:
>> 
>>> On Dec 3, 2018, at 6:52 AM, Robert Engels  wrote:
>>> 
>>> I think people are misunderstanding my equal footing need. I don’t mean for 
>>> all applications, I mean for a application. 
>>> 
>>> Here’s another example. You have a enterprise payroll application. You have 
>>> a model package. You have model.Employee. Having to use model.Employee 
>>> throughout the application is noise. Everyone working on the application 
>>> knows that Employee means model.Employee. It is part of the language (dsl 
>>> in a way) for that application. 
>> 
>> Now suppose you have to write a application that
>> has to access payroll as well as employee performance
>> review, health insurance, expense reporting, connect
>> to 3rd parties for special discounts for various things,
>> etc. Each of these subsystems may have their own
>> definition of Employee (which may be stored in their
>> own databases). This list may grow over time and you
>> don't want to have to recompile and retest *existing*
>> packages by changing some central Employee type.
> 

-- 
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] Package Stutter

[Robert Engels]

Anyway, thanks all for the input. I am continuing to review other large code 
based for real world examples for what works and what doesn’t and having the 
input of the community makes understanding the conventions easier. 

> On Dec 3, 2018, at 10:08 AM, Robert Engels  wrote:
> 
> I understand that, and when working in code that uses both types, which is 
> probably limited, you fully qualify. This is pretty standard stuff in the 
> enterprise world, as well architected solutions are segmented, so you only 
> encounter this problem at the integration points, and that code is qualified. 
> 
> You have a similar problem if both applications have a model package. Now you 
> need to override the import on one of them. No difference IMO. 
> 
>>> On Dec 3, 2018, at 10:03 AM, Bakul Shah  wrote:
>>> 
>>> On Dec 3, 2018, at 6:52 AM, Robert Engels  wrote:
>>> 
>>> I think people are misunderstanding my equal footing need. I don’t mean for 
>>> all applications, I mean for a application. 
>>> 
>>> Here’s another example. You have a enterprise payroll application. You have 
>>> a model package. You have model.Employee. Having to use model.Employee 
>>> throughout the application is noise. Everyone working on the application 
>>> knows that Employee means model.Employee. It is part of the language (dsl 
>>> in a way) for that application. 
>> 
>> Now suppose you have to write a application that
>> has to access payroll as well as employee performance
>> review, health insurance, expense reporting, connect
>> to 3rd parties for special discounts for various things,
>> etc. Each of these subsystems may have their own
>> definition of Employee (which may be stored in their
>> own databases). This list may grow over time and you
>> don't want to have to recompile and retest *existing*
>> packages by changing some central Employee type.
> 
> -- 
> 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] Package Stutter

[Robert Engels]

I understand that, and when working in code that uses both types, which is 
probably limited, you fully qualify. This is pretty standard stuff in the 
enterprise world, as well architected solutions are segmented, so you only 
encounter this problem at the integration points, and that code is qualified. 

You have a similar problem if both applications have a model package. Now you 
need to override the import on one of them. No difference IMO. 

> On Dec 3, 2018, at 10:03 AM, Bakul Shah  wrote:
> 
>> On Dec 3, 2018, at 6:52 AM, Robert Engels  wrote:
>> 
>> I think people are misunderstanding my equal footing need. I don’t mean for 
>> all applications, I mean for a application. 
>> 
>> Here’s another example. You have a enterprise payroll application. You have 
>> a model package. You have model.Employee. Having to use model.Employee 
>> throughout the application is noise. Everyone working on the application 
>> knows that Employee means model.Employee. It is part of the language (dsl in 
>> a way) for that application. 
> 
> Now suppose you have to write a application that
> has to access payroll as well as employee performance
> review, health insurance, expense reporting, connect
> to 3rd parties for special discounts for various things,
> etc. Each of these subsystems may have their own
> definition of Employee (which may be stored in their
> own databases). This list may grow over time and you
> don't want to have to recompile and retest *existing*
> packages by changing some central Employee type.

-- 
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] Package Stutter

[Bakul Shah]

On Dec 3, 2018, at 6:52 AM, Robert Engels  wrote:
> 
> I think people are misunderstanding my equal footing need. I don’t mean for 
> all applications, I mean for a application. 
> 
> Here’s another example. You have a enterprise payroll application. You have a 
> model package. You have model.Employee. Having to use model.Employee 
> throughout the application is noise. Everyone working on the application 
> knows that Employee means model.Employee. It is part of the language (dsl in 
> a way) for that application. 

Now suppose you have to write a application that
has to access payroll as well as employee performance
review, health insurance, expense reporting, connect
to 3rd parties for special discounts for various things,
etc. Each of these subsystems may have their own
definition of Employee (which may be stored in their
own databases). This list may grow over time and you
don't want to have to recompile and retest *existing*
packages by changing some central Employee type.

-- 
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] Package Stutter

[roger peppe]

On Mon, 3 Dec 2018 at 14:52, Robert Engels  wrote:

> I think people are misunderstanding my equal footing need. I don’t mean
> for all applications, I mean for a application.
>

> Here’s another example. You have a enterprise payroll application. You
> have a model package. You have model.Employee. Having to use model.Employee
> throughout the application is noise. Everyone working on the application
> knows that Employee means model.Employee. It is part of the language (dsl
> in a way) for that application.
>

"Everyone" might not be as many people as you think... Your model package
is likely to have many types in it - are they *all *equally known by
everybody. What about when you add a new type to the model?

One of Go's advantages is the way that people can go into a strange code
base and quickly understand how things work. When someone new starts
working on that application, they'll be in that position. When you go back
to working on that application after a while, you might be in that same
position too. Go does not strive to be a terse language and this is one of
those times when we pay the price of some verbosity for more general
readability and lack of cognitive load.

There's another issue with using of dot imports. If you import two packages
using dot imports and they define any symbols in common, you'll get a
compiler error. That means that adding a new symbol can become a breaking
change, which is not a desirable property.

-- 
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] Package Stutter

[Robert Engels]

I thought the main was special cased, since the app band is based on the 
directory not the package. 



> On Dec 3, 2018, at 3:04 AM, roger peppe  wrote:
> 
> On Mon, 3 Dec 2018 at 07:40, robert engels  wrote:
> > Roger,
> >
> > I experimented with the import name (rather than dot import), and came up 
> > with this:
> >
> > type Order struct {
> >sync.RWMutex
> >Instrument
> >Id OrderID
> >ExchangeId string
> >Price  n.Fixed
> >Side
> >Quantity   n.Fixed
> >Remaining  n.Fixed
> >OrderType
> >OrderState
> >RejectReason string
> > }
> >
> > But I’m still not sure it’s great. The n (number) has some meaning, and it 
> > definitely reads easier than fixed.Fixed, but I what I’m really trying to 
> > convey is that “Fixed” is a top-level type, on equal footing with ‘string’.
> 
> But it really isn't a top-level type on an equal footing with string. Type 
> "string" is defined by the language and is common with every other Go program 
> in existence. Your "Fixed" type may be one of many implementations, each with 
> its own particular set of operations and conventions.
> 
> That said, you could do:
> 
>  type fixed = fixed.Fixed
> 
> > OrderID is declared in this package, so it reads with the desired 
> > simplicity, and it just seems wrong that I can’t declare Fixed to have the 
> > same treatment just because it comes from another package.
> 
> Knowing which things come from external packages is an important part of 
> understanding the code.
> 
> BTW I wonder if a single capital letter might work well for single letter 
> import identifiers, because that's a space that's not commonly used (with the 
> exception of the "C" pseudo import). e.g. N.Fixed. Then it wouldn't clash 
> with commonly used single letter identifiers such as "n".
> > Anyway, I’ve read through your proposal, and I didn’t even think it was 
> > possible… :)
> >
> > I thought the last segment needed to match the package name. What would be 
> > the rationale for not having that be the case (i.e. why is that even 
> > supported ?)
> 
> Trivially, every "main" package has this issue, as does any package with a 
> trailing major version (e.g. google.golang.org/api/compute/v1, 
> gopkg.in/yaml.v2, cloud.google.com/go/container/apiv1). There are quite a few 
> packages that use a punctuation-separated last component (e.g. 
> github.com/juju/persistent-cookiejar, code.google.com/p/biogo.llrb) and 
> others that just seem to use a different identifier anyway (e.g. 
> upspin.io/pack/eeintegrity has name "ei" not "eeintegrity").
> 
> I don't think it's a good idea to encapsulate some of the above conventions 
> in the language spec; better just to define a simple rule and an easy way to 
> get around it when it doesn't fit, I think.
> 
>   cheers,
> rog.
> 
> PS embedding Mutex into a public is generally considered not to be a good 
> idea, as it means that external code can break mutex invariants. It's 
> considered better to keep mutex-manipulating code encapsulated inside methods 
> or functions - that way, all lock manipulations can easily be audited.
> -- 
> 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] Package Stutter

[Robert Engels]

I think people are misunderstanding my equal footing need. I don’t mean for all 
applications, I mean for a application. 

Here’s another example. You have a enterprise payroll application. You have a 
model package. You have model.Employee. Having to use model.Employee throughout 
the application is noise. Everyone working on the application knows that 
Employee means model.Employee. It is part of the language (dsl in a way) for 
that application. 


> On Dec 3, 2018, at 5:31 AM, Bakul Shah  wrote:
> 
>> On Dec 2, 2018, at 11:39 PM, robert engels  wrote:
>> 
>> what I’m really trying to convey is that “Fixed” is a top-level type, on 
>> equal footing with ‘string’.
> 
> a) it is *not* on equal footing with the built in types of Go.
> b) it can't be, as "Fixed" by itself not well defined. The
>   Fixed type in your pkg assumes a specific scale factor,
>   which may not be right for everyone. In general you'd have
>   to allow specifying the fractional parr. For example, PL/I
>   provides
>FIXED BINARY(number of bits, fractional bits) &
>FIXED DECIMAL(number of digits, fractional digits)
>   for this purpose. The Fixed type in your pkg is *roughly*
>   equivalent to FIXED DECIMAL(19,7). Fixed types have a
>   very limited use so it wouldn't make sense to add them to
>   a general purpose language such as Go. 
> 
> On dot imports. It is a bad idea. Everyone with far more
> experience than you or I have said the same thing and given
> their reasons. I suspect you will come around their PoV over
> time!
> 
> -- 
> 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] Package Stutter

[Bakul Shah]

On Dec 2, 2018, at 11:39 PM, robert engels  wrote:
> 
> what I’m really trying to convey is that “Fixed” is a top-level type, on 
> equal footing with ‘string’.

a) it is *not* on equal footing with the built in types of Go.
b) it can't be, as "Fixed" by itself not well defined. The
   Fixed type in your pkg assumes a specific scale factor,
   which may not be right for everyone. In general you'd have
   to allow specifying the fractional parr. For example, PL/I
   provides
FIXED BINARY(number of bits, fractional bits) &
FIXED DECIMAL(number of digits, fractional digits)
   for this purpose. The Fixed type in your pkg is *roughly*
   equivalent to FIXED DECIMAL(19,7). Fixed types have a
   very limited use so it wouldn't make sense to add them to
   a general purpose language such as Go. 

On dot imports. It is a bad idea. Everyone with far more
experience than you or I have said the same thing and given
their reasons. I suspect you will come around their PoV over
time!

-- 
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] Package Stutter

[Jan Mercl]

On Mon, Dec 3, 2018 at 10:05 AM roger peppe  wrote:

> That said, you could do:
>
> type fixed = fixed.Fixed

FTR: That's invalid code, it redeclares 'fixed'. (Go forbids the same
identifier to live in package scope and file scope.)

-- 
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] Package Stutter

[roger peppe]

On Mon, 3 Dec 2018 at 07:40, robert engels  wrote:
> Roger,
>
> I experimented with the import name (rather than dot import), and came up
with this:
>
> type Order struct {
>sync.RWMutex
>Instrument
>Id OrderID
>ExchangeId string
>Price  n.Fixed
>Side
>Quantity   n.Fixed
>Remaining  n.Fixed
>OrderType
>OrderState
>RejectReason string
> }
>
> But I’m still not sure it’s great. The n (number) has some meaning, and
it definitely reads easier than fixed.Fixed, but I what I’m really trying
to convey is that “Fixed” is a top-level type, on equal footing with
‘string’.

But it really *isn't* a top-level type on an equal footing with string.
Type "string" is defined by the language and is common with every other Go
program in existence. Your "Fixed" type may be one of many implementations,
each with its own particular set of operations and conventions.

That said, you could do:

 type fixed = fixed.Fixed

> OrderID is declared in this package, so it reads with the desired
simplicity, and it just seems wrong that I can’t declare Fixed to have the
same treatment just because it comes from another package.

Knowing which things come from external packages is an important part of
understanding the code.

BTW I wonder if a single capital letter might work well for single letter
import identifiers, because that's a space that's not commonly used (with
the exception of the "C" pseudo import). e.g. N.Fixed. Then it wouldn't
clash with commonly used single letter identifiers such as "n".
> Anyway, I’ve read through your proposal, and I didn’t even think it was
possible… :)
>
> I thought the last segment needed to match the package name. What would
be the rationale for not having that be the case (i.e. why is that even
supported ?)

Trivially, every "main" package has this issue, as does any package with a
trailing major version (e.g. google.golang.org/api/compute/v1,
gopkg.in/yaml.v2, cloud.google.com/go/container/apiv1). There are quite a
few packages that use a punctuation-separated last component (e.g.
github.com/juju/persistent-cookiejar, code.google.com/p/biogo.llrb) and
others that just seem to use a different identifier anyway (e.g.
upspin.io/pack/eeintegrity has name "ei" not "eeintegrity").

I don't think it's a good idea to encapsulate some of the above conventions
in the language spec; better just to define a simple rule and an easy way
to get around it when it doesn't fit, I think.

  cheers,
rog.

PS embedding Mutex into a public is generally considered not to be a good
idea, as it means that external code can break mutex invariants. It's
considered better to keep mutex-manipulating code encapsulated inside
methods or functions - that way, all lock manipulations can easily be
audited.

-- 
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] Package Stutter

[robert engels]

Roger,

I experimented with the import name (rather than dot import), and came up with 
this:

type Order struct {
   sync.RWMutex
   Instrument
   Id OrderID
   ExchangeId string
   Price  n.Fixed
   Side
   Quantity   n.Fixed
   Remaining  n.Fixed
   OrderType
   OrderState
   RejectReason string
}
But I’m still not sure it’s great. The n (number) has some meaning, and it 
definitely reads easier than fixed.Fixed, but I what I’m really trying to 
convey is that “Fixed” is a top-level type, on equal footing with ‘string’.

OrderID is declared in this package, so it reads with the desired simplicity, 
and it just seems wrong that I can’t declare Fixed to have the same treatment 
just because it comes from another package.

Anyway, I’ve read through your proposal, and I didn’t even think it was 
possible… :)

I thought the last segment needed to match the package name. What would be the 
rationale for not having that be the case (i.e. why is that even supported ?)






> On Dec 2, 2018, at 12:33 PM, roger peppe  wrote:
> 
> > Do you really think you are losing information if this becomes:
> > 
> > func matches(p Policy, a authorizer.Attributes) bool {
> 
> From my point of view, yes it makes a big difference if I see a 
> package-qualified identifier, because I know that it's invoking some other 
> package's abstraction. I am very often traversing some code that I am not 
> familiar with, and arbitrary names imported from external packages make that 
> harder. It also makes it significantly harder to refactor code.
> 
> In short, although there is a cost to qualifying external names, I believe 
> that cost is justified.
> 
> If you wish to lower the overhead of package qualifiers for frequently used 
> names, there are alternatives to dot imports. You could specify a short (one 
> or two character) identifier instead of the default package name. We do this 
> a lot for some DSL-like packages. You could also define local type aliases - 
> e.g. type policy = abac.Policy, or local function wrappers (mid-stack 
> inlining should make that zero-cost at some point).
> 
> FYI I have created a Go proposal related to this that you might wish to give 
> feedback on: 
> https://github.com/golang/go/issues/29036#issuecomment-443311975 
> 
> 
> On Sun, 2 Dec 2018, 5:59 am robert engels   wrote:
> As some supporting evidence, here is a method signature in k8s:
> 
> func matches(p abac.Policy, a authorizer.Attributes) bool {
> 
> The interesting aspect is that this method is in package abac, except it is 
> in pkg/auth/authorizer/abac
> 
> and the one being used in the method
> 
> pkg/apis/abac
> 
> Do you really think you are losing information if this becomes:
> 
> func matches(p Policy, a authorizer.Attributes) bool {
> 
> The developer needs to do mental work in either case. I left the authorizer 
> on purpose, because Attributes is too generic to be useful. Granted, their 
> package structure seems poor in my opinion, but you can’t talk bad about k8s.
> 
> Here’s an easier example from k8s:
> 
> func (dsc *DaemonSetsController) enqueueDaemonSetAfter(obj interface{}, after 
> time.Duration) {
> 
> Is that any better than 
> 
> func (dsc *DaemonSetsController) enqueueDaemonSetAfter(obj interface{}, after 
> Duration) {
> 
> And another:
> 
> func deleteOwnerRefStrategicMergePatch(dependentUID types.UID, ownerUIDs 
> ...types.UID) []byte {
> 
> Is that really better than:
> 
> func deleteOwnerRefStrategicMergePatch(dependentUID UID, ownerUIDs ...UID) 
> []byte {
> 
> 
> If you need a package named types, it is probably ubiquitous throughout the 
> codebase, so using type.UID everyplace is just noise.
> 
> And probably the most common method signature of them all:
> http.HandleFunc("/bar", func(w http.ResponseWriter, r *http.Request) {
> are you losing anything if this is:
> http.HandleFunc("/bar", func(w ResponseWriter, r *Request) {
> I would argue you are actually gaining something, as the Request above might 
> be a facade with extra properties etc. The compiler will inform you if you 
> use an incorrect property, and an IDE will give you the method/properties as 
> you code, so its completely safe. Now, you might be thinking, request is 
> pretty generic, so this is not the best example (because a web app probably 
> has lots of different types of Request, and it could quickly become 
> confusing, but wait, the http.HandleFunc removes any ambiguity.
> 
> All coding requires good development choices - there are many times it 
> probably shouldn’t be used -  but I making a blanket statement its bad seems 
> like overreach.
> 
> 
>> On Dec 1, 2018, at 11:19 PM, Robert Engels > > wrote:
>> 
>> I know everyone hates it when I reference java but it has had dot imports at 
>> the package level since day one. I won’t repeat why that matters. It’s never 
>> been a problem.
>> 
>> I don’t 

Re: [go-nuts] Package Stutter

[Robert Engels]

I agree that is an important consideration, but it seems less important if the 
packages are small and focused. 

I think an important point to consider is that there are systems apps, and 
enterprise apps. These rules seem well suited to systems apps, but maybe not so 
well suited to business enterprise apps. 

As I become more familiar with Go I become more convinced that is great for 
systems apps, and not very workable for business apps. I’m trying to work on 
some things that might change the latter, but to get there I’m trying to fully 
understand the thinking behind these design decisions. 

> On Dec 2, 2018, at 10:56 PM, Ian Lance Taylor  wrote:
> 
>> On Sat, Dec 1, 2018 at 7:25 PM Robert Engels  wrote:
>> 
>> The way to fix it though it just to use dot imports, and encourage it! The 
>> only time dot imports don’t work is when there isn’t package stutter. Seems 
>> like a no brainer and you get the best of both worlds.
> 
> Go programs that do not use dot imports have the convenient feature
> that any unqualified name must be defined somewhere in the same
> package.  The first component of any qualified name must be either
> defined in the same package or be the name of a package imported in
> the same file.  These convenient facts make it easier to read Go code
> and quickly understand where each name is coming from.
> 
> 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] Package Stutter

[Ian Lance Taylor]

On Sat, Dec 1, 2018 at 7:25 PM Robert Engels  wrote:
>
> The way to fix it though it just to use dot imports, and encourage it! The 
> only time dot imports don’t work is when there isn’t package stutter. Seems 
> like a no brainer and you get the best of both worlds.

Go programs that do not use dot imports have the convenient feature
that any unqualified name must be defined somewhere in the same
package.  The first component of any qualified name must be either
defined in the same package or be the name of a package imported in
the same file.  These convenient facts make it easier to read Go code
and quickly understand where each name is coming from.

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] Package Stutter

[roger peppe]

> Do you really think you are losing information if this becomes:
>
> func matches(p Policy, a authorizer.Attributes) bool {

>From my point of view, yes it makes a big difference if I see a
package-qualified identifier, because I know that it's invoking some other
package's abstraction. I am very often traversing some code that I am not
familiar with, and arbitrary names imported from external packages make
that harder. It also makes it significantly harder to refactor code.

In short, although there is a cost to qualifying external names, I believe
that cost is justified.

If you wish to lower the overhead of package qualifiers for frequently used
names, there are alternatives to dot imports. You could specify a short
(one or two character) identifier instead of the default package name. We
do this a lot for some DSL-like packages. You could also define local type
aliases - e.g. type policy = abac.Policy, or local function wrappers
(mid-stack inlining should make that zero-cost at some point).

FYI I have created a Go proposal related to this that you might wish to
give feedback on:
https://github.com/golang/go/issues/29036#issuecomment-443311975

On Sun, 2 Dec 2018, 5:59 am robert engels  As some supporting evidence, here is a method signature in k8s:
>
> func matches(p abac.Policy, a authorizer.Attributes) bool {
>
> The interesting aspect is that this method is in package abac, except it
> is in pkg/auth/authorizer/abac
>
> and the one being used in the method
>
> pkg/apis/abac
>
> Do you really think you are losing information if this becomes:
>
> func matches(p Policy, a authorizer.Attributes) bool {
>
> The developer needs to do mental work in either case. I left the
> authorizer on purpose, because Attributes is too generic to be useful.
> Granted, their package structure seems poor in my opinion, but you can’t
> talk bad about k8s.
>
> Here’s an easier example from k8s:
>
> func (dsc *DaemonSetsController) enqueueDaemonSetAfter(obj interface{},
> after time.Duration) {
>
> Is that any better than
>
> func (dsc *DaemonSetsController) enqueueDaemonSetAfter(obj interface{},
> after Duration) {
>
> And another:
>
> func deleteOwnerRefStrategicMergePatch(dependentUID types.UID, ownerUIDs
> ...types.UID) []byte {
>
> Is that really better than:
>
> func deleteOwnerRefStrategicMergePatch(dependentUID UID, ownerUIDs ...UID)
> []byte {
>
>
> If you need a package named types, it is probably ubiquitous throughout
> the codebase, so using type.UID everyplace is just noise.
>
> And probably the most common method signature of them all:
>
> http.HandleFunc("/bar", func(w http.ResponseWriter, r *http.Request) {
>
> are you losing anything if this is:
>
> http.HandleFunc("/bar", func(w ResponseWriter, r *Request) {
>
> I would argue you are actually gaining something, as the Request above
> might be a facade with extra properties etc. The compiler will inform you
> if you use an incorrect property, and an IDE will give you the
> method/properties as you code, so its completely safe. Now, you might be
> thinking, request is pretty generic, so this is not the best example
> (because a web app probably has lots of different types of Request, and it
> could quickly become confusing, but wait, the http.HandleFunc removes any
> ambiguity.
>
> All coding requires good development choices - there are many times it
> probably shouldn’t be used -  but I making a blanket statement its bad
> seems like overreach.
>
>
> On Dec 1, 2018, at 11:19 PM, Robert Engels  wrote:
>
> I know everyone hates it when I reference java but it has had dot imports
> at the package level since day one. I won’t repeat why that matters. It’s
> never been a problem.
>
> I don’t think I ever heard someone complain it was a problem in working in
> Java, why is it such a problem in Go? I’m suspecting it’s because people’s
> packages are too large in scope so they end importing tons of external
> packages. It’s a structure problem not a language feature problem.
>
> On Dec 1, 2018, at 11:08 PM, Ian Denhardt  wrote:
>
> Quoting Robert Engels (2018-12-01 22:25:06)
>
> The way to fix it though it just to use dot imports, and encourage it!
> The only time dot imports don't work is when there isn't package
> stutter. Seems like a no brainer and you get the best of both worlds.
>
>
> My experience in every language I've worked with that has an equivalent
> of dot imports has been: this is more trouble than it's worth. It hurts
> readability of large codebases more than any other single language
> feature I can think of, and this has been my experience in everything
> from Python to Haskell.
>
> It is sometimes nice for DSLs -- Elm has an Html module that just
> defines a function per html element, and folks usually "dot import"
> that whole module. But they basically never "dot import" *anything*
> else, and doing it in the general case is similarly discouraged. In
> languages where I've seen *common* use of it, I've come to the
> conclusion that it 

Re: [go-nuts] Package Stutter

['Niko Schwarz' via golang-nuts]

For what it's worth, in all this time, context.Context still looks clumsy 
to me and I wish you'd picked context.Ctx :)

My certainty level here is high, the intensity level is low. It's like: I'm 
pretty sure I like the red backpack better than the black one. But the 
black one is fine :)

Niko

On Sunday, December 2, 2018 at 3:52:03 AM UTC+1, Sameer Ajmani wrote:
>
> For what it's worth, we considered various ways to shorten context.Context 
> before releasing it as open source. The obvious choice would be context.C, 
> but I was concerned this would encourage people to name their context 
> variables c, which conflicts with the common short name for channel 
> variables. Since we typically use the short name ctx, we also considered 
> the type name context.Ctx, but this seemed too arbitrary. We went with 
> context.Context because it's clear and doesn't introduce any unnecessary 
> confusion.
> S
> On Sat, Dec 1, 2018 at 1:25 PM Robert Engels  > wrote:
>
>> I agree. You need to understand the expected usage patterns (and possibly 
>> other external and internal constraints) before you can claim that any 
>> design “needs change”. 
>>
>> On Dec 1, 2018, at 12:18 PM, Bakul Shah > > wrote:
>>
>> Reducing stutter.Stutter is a good thing. But coming up with meaningful
>> names ThatDontTakeHalfALineAndReduceCodeDensity is often quite
>> hard (but ultimately rewarding as it forces you to think more clearly).
>> And languages and practices evolve as people gain more experience
>> so early practices should not be seen as a model for newer code.
>>
>> Nigel Tao mentioned fixed.Int26_6, which is much more useful as it shows
>> where the fixed point lies for this type. In my case I used currency.Type 
>> for
>> its main type, not currency.Currency. The "fixed point" may in fact depend
>> on a specific currency.
>>
>> Bottom line: think of "reduce stutter" as a *best practice* but not a 
>> *rule*!
>>
>> On Dec 1, 2018, at 9:53 AM, Robert Engels > > wrote:
>>
>> That was my point. The earliest practitioners and language designers used 
>> the construct extensively but now others claim it is not the way. I find it 
>> hard to believe that in testing the original Go design the creators didn’t 
>> think about this - which means they decided it was fine. So why the change?
>>
>> On Dec 1, 2018, at 11:01 AM, Tristan Colgate > > wrote:
>>
>> In the cases of time and context, the stutters appear in a primary type 
>> that is important to the package, but rarely appears directly in normal API 
>> usage.
>>   E.g., time.Now(), context.Background().  
>>   Stutter is to be avoided. The package name can provide context. But 
>> stutter is preferred to, e.g. time.Type, where one package largely operates 
>> on one type
>>   I doubt there would be a peer reviewed paper on something which is 
>> basically just an opinion held by the language's earliest practitioners. It 
>> doesn't mean the idea does not have merit though.
>>
>> On Sat, 1 Dec 2018, 14:19 Robert Engels, > > wrote:
>>
>>> In another thread, it has been brought up that things like time.Time are 
>>> no good. But this format is pervasive. Even newer packages like 
>>> context.Context.
>>>
>>> It seems to have been this way for a long time. 
>>>
>>> It there some reasoned paper on why this is now so frowned upon?
>>>
>>> -- 
>>> 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...@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...@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] Package Stutter

[Robert Engels]

If can go as far as

List list = sort(reverse(somelist))

I understand the import problem is not an issue when writing a package, but 
it’s a big issue when the use of the package is extensive, like domain types. 
It’s just cumbersome noise at that point, and a solution is needed IMO. 

> On Dec 2, 2018, at 2:55 AM, Dan Kortschak  wrote:
> 
> That's pretty different to a dot import in Go. If the imports below
> gave you 
> 
> List list = singletonList(someobject)
> 
> Then they would be comparable - the static imports are more comparable
> to Go's dot imports, but then in your next post you say that they're
> mainly used for constants, "although for some types of routines it is
> used to make the code read like a DSL."
> 
> 
> 
>> On Sun, 2018-12-02 at 00:04 -0600, robert engels wrote:
>> When you use
>> 
>> import java.util.Collections;
>> import java.util.List;
>> 
>> You are actually doing a dot import, so you can in the code just
>> refer to it as so
>> 
>> List list = Collections.singletonList(someobject)
>> 
>> otherwise you need to write the code as:
>> 
>> java.util.List list =
>> java.util.Collections.singletonList(someobject);
> 
> -- 
> 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] Package Stutter

[Dan Kortschak]

That's pretty different to a dot import in Go. If the imports below
gave you 

List list = singletonList(someobject)

Then they would be comparable - the static imports are more comparable
to Go's dot imports, but then in your next post you say that they're
mainly used for constants, "although for some types of routines it is
used to make the code read like a DSL."



On Sun, 2018-12-02 at 00:04 -0600, robert engels wrote:
> When you use
> 
> import java.util.Collections;
> import java.util.List;
> 
> You are actually doing a dot import, so you can in the code just
> refer to it as so
> 
> List list = Collections.singletonList(someobject)
> 
> otherwise you need to write the code as:
> 
> java.util.List list =
> java.util.Collections.singletonList(someobject);

-- 
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] Package Stutter

[Ian Denhardt]

Quoting robert engels (2018-12-02 01:55:17)

> added to Go, but I am not sure if the package has a few related types
> (which it should IMO) it is any better than
>
> import . “package”

This also exposes stand-alone functions, constants etc. which doesn't
come up in Java.

I think the stutter really is specific to packages that have a "primary"
type, and then it's generally just the one type name around which it
occurs. In Elm we tend to do exposing (TheType) and leave everything
else qualified.

-- 
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] Package Stutter

[Sanjay]

In both Java and C++ (statically compiled languages), Google's style guides 
prohibit "wildcard"-style imports of an entire library:
https://google.github.io/styleguide/javaguide.html#s3.3.1-wildcard-imports
https://google.github.io/styleguide/cppguide.html#Namespaces

I believe the restriction is there to allow library authors to add names to 
their library over time without the risk of changing the meaning of calling 
code (or making that code fail to compile).

I used to find working with Java imports fairly unpleasant as it requires 
editing imports once for every type mentioned, rather than every package. 
Luckily, there is goimports-inspired tooling for this (although it is much 
slower, sadly).

In any case, I can maybe see why you'd want to use unqualified types, but 
it seems valuable to know at the use-site which identifiers originate in 
different packages, and which must originate in the same package. That 
value seems worth prohibiting dot-imports. You occasionally have to deal 
with things like "context.Context", but they are the exception not the rule 
(there are more names in the io package alone than have been mentioned as 
stutter here in this thread).

Sanjay


On Saturday, December 1, 2018 at 10:44:05 PM UTC-8, robert engels wrote:
>
> I think it is especially problematic for python because: 
>
> import * +  type inference + dynamic language = hell 
>
> in my book. 
>
> > On Dec 2, 2018, at 12:26 AM, Ian Denhardt  > wrote: 
> > 
> > Quoting robert engels (2018-12-02 00:59:31) 
> > 
> >>   Granted, their package structure seems poor in my opinion, but you 
> >>   can't talk bad about k8s. 
> > 
> > Of course you don't lose anything by getting rid of the package names if 
> > the package structure doesn't make any sense in the first place. 
> > 
> >>   And probably the most common method signature of them all: 
> >> 
> >> http.HandleFunc("/bar", func(w http.ResponseWriter, r *http.Request) { 
> >> 
> >>   are you losing anything if this is: 
> >> http.HandleFunc("/bar", func(w ResponseWriter, r *Request) { 
> > 
> > No, and I would go further (if Go permitted it): 
> > 
> >http.HandleFunc("/bar", func(w, r) { 
> >... 
> >}) 
> > 
> > http.HandleFunc is so well known that having the types there at all is 
> > just noise. But I know you don't like type inference. 
> > 
> >>   All coding requires good development choices - there are many times 
> it 
> >>   probably shouldn't be used -  but I making a blanket statement its 
> bad 
> >>   seems like overreach. 
> > 
> > It's bad enough that common Python linters will flag it, and a lot of 
> > large python projects do ban it outright. 
> > 
> > Note that nobody in Python land complains about: 
> > 
> >from foo import bar, baz 
> > 
> > ..the equivalent of which is what I've seen in what Java code I have 
> > looked at. Rather, the suspect construct is: 
> > 
> >from foo import * 
> > 
> > -- 
> > 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] Package Stutter

[Ian Denhardt]

Quoting robert engels (2018-12-02 01:43:45)

> import * +  type inference + dynamic language = hell

Can't have type inference without types, so it's just the dynamic bit,
but I basically agree -- combined with the fact that you can do nonsense
black magic with the import machinery at runtime in Python, it makes it
that much worse; you can't even necessarily rely on your tools for
figuring out where things are coming from.

But the code isn't actually much more readable at a glance when people
do it in Haskell; it is at least not *that* hard to track down an
identifier due to there being a strong, static type system, but it
is in my experience still universally easier to read code when there
aren't wildcard imports.

I will grant that probably having neither of these things makes wildcard
imports less of a problem. But again, it seems like wildcard imports
aren't the norm in Java anyway?

-- 
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] Package Stutter

[robert engels]

I was thinking the similarly, which is why I thought about the List case.

In Java, however you get there, it is just referred to as List

In Go, it is going to be list.List

And in a competing implementation it is going to be container.List or whatever 
package the author came up with.

That’s a big difference IMO.

I would be totally in favor of

import Time,Duration from time

added to Go, but I am not sure if the package has a few related types (which it 
should IMO) it is any better than

import . “package”

Have the ‘import from’ been proposed and rejected? Still, it requires using 
‘stutter’ to be workable - but as you know I’m ok with that :)



> On Dec 2, 2018, at 12:40 AM, Ian Denhardt  wrote:
> 
> Based on your explanation, my original understanding of the semantics
> were correct.  This:
> 
>> import java.util.Collections;
> 
> ..is not a dot import -- a dot import makes visible every (exported)
> identifier in the package. This just exposes the one identifier --
> Collections. I don't have a problem with that. The equivalent in Java to
> what I'm complaining about is .*, and it seems like (from my skimming)
> it isn't what people reach for most. (Note that methods are still
> qualified by classes, because they're methods).
> 
> Go does not have an equivalent of:
> 
>import foo.bar.Baz; // java
>from foo.bar import Baz // Python
>import Foo.Bar exposing (Baz) // Elm
> 
> It might be nice if it did; it would be occasionally useful to import
> single identifiers (e.g. Context from context).
> 
> -- 
> 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] Package Stutter

[robert engels]

I think it is especially problematic for python because:

import * +  type inference + dynamic language = hell

in my book.

> On Dec 2, 2018, at 12:26 AM, Ian Denhardt  wrote:
> 
> Quoting robert engels (2018-12-02 00:59:31)
> 
>>   Granted, their package structure seems poor in my opinion, but you
>>   can't talk bad about k8s.
> 
> Of course you don't lose anything by getting rid of the package names if
> the package structure doesn't make any sense in the first place.
> 
>>   And probably the most common method signature of them all:
>> 
>> http.HandleFunc("/bar", func(w http.ResponseWriter, r *http.Request) {
>> 
>>   are you losing anything if this is:
>> http.HandleFunc("/bar", func(w ResponseWriter, r *Request) {
> 
> No, and I would go further (if Go permitted it):
> 
>http.HandleFunc("/bar", func(w, r) {
>...
>})
> 
> http.HandleFunc is so well known that having the types there at all is
> just noise. But I know you don't like type inference.
> 
>>   All coding requires good development choices - there are many times it
>>   probably shouldn't be used -  but I making a blanket statement its bad
>>   seems like overreach.
> 
> It's bad enough that common Python linters will flag it, and a lot of
> large python projects do ban it outright.
> 
> Note that nobody in Python land complains about:
> 
>from foo import bar, baz
> 
> ..the equivalent of which is what I've seen in what Java code I have
> looked at. Rather, the suspect construct is:
> 
>from foo import *
> 
> -- 
> 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] Package Stutter

[Ian Denhardt]

Based on your explanation, my original understanding of the semantics
were correct.  This:

> import java.util.Collections;

..is not a dot import -- a dot import makes visible every (exported)
identifier in the package. This just exposes the one identifier --
Collections. I don't have a problem with that. The equivalent in Java to
what I'm complaining about is .*, and it seems like (from my skimming)
it isn't what people reach for most. (Note that methods are still
qualified by classes, because they're methods).

Go does not have an equivalent of:

import foo.bar.Baz; // java
from foo.bar import Baz // Python
import Foo.Bar exposing (Baz) // Elm

It might be nice if it did; it would be occasionally useful to import
single identifiers (e.g. Context from context).

-- 
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] Package Stutter

[Ian Denhardt]

Quoting robert engels (2018-12-02 00:59:31)

>Granted, their package structure seems poor in my opinion, but you
>can't talk bad about k8s.

Of course you don't lose anything by getting rid of the package names if
the package structure doesn't make any sense in the first place.

>And probably the most common method signature of them all:
>
> http.HandleFunc("/bar", func(w http.ResponseWriter, r *http.Request) {
>
>are you losing anything if this is:
> http.HandleFunc("/bar", func(w ResponseWriter, r *Request) {

No, and I would go further (if Go permitted it):

http.HandleFunc("/bar", func(w, r) {
...
})

http.HandleFunc is so well known that having the types there at all is
just noise. But I know you don't like type inference.

>All coding requires good development choices - there are many times it
>probably shouldn't be used -  but I making a blanket statement its bad
>seems like overreach.

It's bad enough that common Python linters will flag it, and a lot of
large python projects do ban it outright.

Note that nobody in Python land complains about:

from foo import bar, baz

..the equivalent of which is what I've seen in what Java code I have
looked at. Rather, the suspect construct is:

from foo import *

-- 
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] Package Stutter

[robert engels]

And when reading through code no Java developer goes, hmmm I wonder what a List 
is - since List in idiomatic use is the List interface from java.util.List. 
Could it be another List type, possibly the java.awt.List, but that’s only used 
in awt related code, and if it’s truly a different List type, they’ve probably 
decided to use it throughout the application - at least I would.

Say the coders decide to use the Guava libraries - even then, their interfaces 
almost always extend the standard ones, so an ImmutableList interface is still 
a List, and so any of the Guava list implementations could be assigned to it. 
I’m not a big fan of DI, but that’s the essence - everything thing on the left 
is an interface, and usually a well known one, unless the List needs additional 
semantics, like ImmutableList - you might change it to give the code reader 
more information - but still you wouldn’t refer to it at 
com.google.common.collect.ImmutableList, you would import it, and use 
ImmutableList.

Which brings me back to why the ‘stutter’ is useful - it allows dot imports to 
work, without it they cannot.


> On Dec 2, 2018, at 12:04 AM, robert engels  wrote:
> 
> The .* doesn’t mean what you think it does - that just means all of the 
> classes in the package. It is no different than listing them each.
> 
> When you use
> 
> import java.util.Collections;
> import java.util.List;
> 
> You are actually doing a dot import, so you can in the code just refer to it 
> as so
> 
> List list = Collections.singletonList(someobject)
> 
> otherwise you need to write the code as:
> 
> java.util.List list = java.util.Collections.singletonList(someobject);
> 
> 
> 
> 
>> On Dec 1, 2018, at 11:51 PM, Ian Denhardt  wrote:
>> 
>> Quoting Robert Engels (2018-12-02 00:19:40)
>>> I know everyone hates it when I reference java but it has had dot
>>> importsat the package level since day one. I won’t repeat why that
>>> matters. It’s never been a problem.
>>> 
>>> I don’t think I ever heard someone complain it was a problem in
>>> working in Java, why is it such a problem in Go?
>> 
>> I'll admit to not having much experience with large Java projects, so
>> hard for me to say why this would be in Java. But from browsing through
>> the source of a handful of open source Java projects, my first guess is:
>> nobody uses them. It seems the norm is to just import each class you
>> want to use individually; I don't see much .*
>> 
>> This is why it works out in Elm -- because people don't use it much.
>> 
>> -- 
>> 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] Package Stutter

[robert engels]

The ‘static import’ allows you to refer to things like this:

import static java.util.Collections.sort;

public class ScratchTest {
public static void main(String[] args) {
java.util.List list = sort(java.util.Collections.singletonList(new 
Object());
}
}

but typically, the static import is used for constants, although for some types 
of routines it is used to make the code read like a DSL.


> On Dec 2, 2018, at 12:04 AM, robert engels  wrote:
> 
> The .* doesn’t mean what you think it does - that just means all of the 
> classes in the package. It is no different than listing them each.
> 
> When you use
> 
> import java.util.Collections;
> import java.util.List;
> 
> You are actually doing a dot import, so you can in the code just refer to it 
> as so
> 
> List list = Collections.singletonList(someobject)
> 
> otherwise you need to write the code as:
> 
> java.util.List list = java.util.Collections.singletonList(someobject);
> 
> 
> 
> 
>> On Dec 1, 2018, at 11:51 PM, Ian Denhardt  wrote:
>> 
>> Quoting Robert Engels (2018-12-02 00:19:40)
>>> I know everyone hates it when I reference java but it has had dot
>>> importsat the package level since day one. I won’t repeat why that
>>> matters. It’s never been a problem.
>>> 
>>> I don’t think I ever heard someone complain it was a problem in
>>> working in Java, why is it such a problem in Go?
>> 
>> I'll admit to not having much experience with large Java projects, so
>> hard for me to say why this would be in Java. But from browsing through
>> the source of a handful of open source Java projects, my first guess is:
>> nobody uses them. It seems the norm is to just import each class you
>> want to use individually; I don't see much .*
>> 
>> This is why it works out in Elm -- because people don't use it much.
>> 
>> -- 
>> 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] Package Stutter

[robert engels]

The .* doesn’t mean what you think it does - that just means all of the classes 
in the package. It is no different than listing them each.

When you use

import java.util.Collections;
import java.util.List;

You are actually doing a dot import, so you can in the code just refer to it as 
so

List list = Collections.singletonList(someobject)

otherwise you need to write the code as:

java.util.List list = java.util.Collections.singletonList(someobject);




> On Dec 1, 2018, at 11:51 PM, Ian Denhardt  wrote:
> 
> Quoting Robert Engels (2018-12-02 00:19:40)
>> I know everyone hates it when I reference java but it has had dot
>> importsat the package level since day one. I won’t repeat why that
>> matters. It’s never been a problem.
>> 
>> I don’t think I ever heard someone complain it was a problem in
>> working in Java, why is it such a problem in Go?
> 
> I'll admit to not having much experience with large Java projects, so
> hard for me to say why this would be in Java. But from browsing through
> the source of a handful of open source Java projects, my first guess is:
> nobody uses them. It seems the norm is to just import each class you
> want to use individually; I don't see much .*
> 
> This is why it works out in Elm -- because people don't use it much.
> 
> -- 
> 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] Package Stutter

[robert engels]

As some supporting evidence, here is a method signature in k8s:

func matches(p abac.Policy, a authorizer.Attributes) bool {

The interesting aspect is that this method is in package abac, except it is in 
pkg/auth/authorizer/abac

and the one being used in the method

pkg/apis/abac

Do you really think you are losing information if this becomes:

func matches(p Policy, a authorizer.Attributes) bool {

The developer needs to do mental work in either case. I left the authorizer on 
purpose, because Attributes is too generic to be useful. Granted, their package 
structure seems poor in my opinion, but you can’t talk bad about k8s.

Here’s an easier example from k8s:

func (dsc *DaemonSetsController) enqueueDaemonSetAfter(obj interface{}, after 
time.Duration) {

Is that any better than 

func (dsc *DaemonSetsController) enqueueDaemonSetAfter(obj interface{}, after 
Duration) {

And another:

func deleteOwnerRefStrategicMergePatch(dependentUID types.UID, ownerUIDs 
...types.UID) []byte {

Is that really better than:

func deleteOwnerRefStrategicMergePatch(dependentUID UID, ownerUIDs ...UID) 
[]byte {


If you need a package named types, it is probably ubiquitous throughout the 
codebase, so using type.UID everyplace is just noise.

And probably the most common method signature of them all:
http.HandleFunc("/bar", func(w http.ResponseWriter, r *http.Request) {
are you losing anything if this is:
http.HandleFunc("/bar", func(w ResponseWriter, r *Request) {
I would argue you are actually gaining something, as the Request above might be 
a facade with extra properties etc. The compiler will inform you if you use an 
incorrect property, and an IDE will give you the method/properties as you code, 
so its completely safe. Now, you might be thinking, request is pretty generic, 
so this is not the best example (because a web app probably has lots of 
different types of Request, and it could quickly become confusing, but wait, 
the http.HandleFunc removes any ambiguity.

All coding requires good development choices - there are many times it probably 
shouldn’t be used -  but I making a blanket statement its bad seems like 
overreach.


> On Dec 1, 2018, at 11:19 PM, Robert Engels  wrote:
> 
> I know everyone hates it when I reference java but it has had dot imports at 
> the package level since day one. I won’t repeat why that matters. It’s never 
> been a problem.
> 
> I don’t think I ever heard someone complain it was a problem in working in 
> Java, why is it such a problem in Go? I’m suspecting it’s because people’s 
> packages are too large in scope so they end importing tons of external 
> packages. It’s a structure problem not a language feature problem. 
> 
>> On Dec 1, 2018, at 11:08 PM, Ian Denhardt  wrote:
>> 
>> Quoting Robert Engels (2018-12-01 22:25:06)
>> 
>>> The way to fix it though it just to use dot imports, and encourage it!
>>> The only time dot imports don't work is when there isn't package
>>> stutter. Seems like a no brainer and you get the best of both worlds.
>> 
>> My experience in every language I've worked with that has an equivalent
>> of dot imports has been: this is more trouble than it's worth. It hurts
>> readability of large codebases more than any other single language
>> feature I can think of, and this has been my experience in everything
>> from Python to Haskell.
>> 
>> It is sometimes nice for DSLs -- Elm has an Html module that just
>> defines a function per html element, and folks usually "dot import"
>> that whole module. But they basically never "dot import" *anything*
>> else, and doing it in the general case is similarly discouraged. In
>> languages where I've seen *common* use of it, I've come to the
>> conclusion that it basically doesn't scale beyond one package, which
>> has to be something that everyone in the language community knows well.
>> In Elm it's Html. In Go it's the set of built-in identifiers. That's all
>> we get.
>> 
>> ---
>> 
>> There really is something special about a package's "main" type here
>> (when it has one) that makes the stutter a bit hard to work around
>> sometimes.  It's a bit unfortunate to have to write context.Context, but
>> nothing *else* in the context package has this problem. Much of the
>> OCaml community has gone with the convention of just calling the type
>> 't' and using the module name to distinguish, and it works pretty well.
>> 
>> In Elm you see a lot of this:
>> 
>>   import Json.Decoder exposing (Decoder)
>> 
>> ..which imports the Decoder type from that module unqualified, and
>> leaves the rest qualified.
>> 
>> I find it a bit unfortunate that the stuttery approach to naming primary
>> times has ended up being the norm in Go, but I do think idiom is worth
>> something; doing pkg.T is a little surprising to me when reading Go
>> code, even though it isn't when reading OCaml.
>> 
>>>  People say, it makes things less clear, and I counter that variable
>>>  inference is far worse and it's done for the sake of less 

Re: [go-nuts] Package Stutter

[Ian Denhardt]

Quoting Robert Engels (2018-12-02 00:19:40)
> I know everyone hates it when I reference java but it has had dot
> importsat the package level since day one. I won’t repeat why that
> matters. It’s never been a problem.
>
> I don’t think I ever heard someone complain it was a problem in
> working in Java, why is it such a problem in Go?

I'll admit to not having much experience with large Java projects, so
hard for me to say why this would be in Java. But from browsing through
the source of a handful of open source Java projects, my first guess is:
nobody uses them. It seems the norm is to just import each class you
want to use individually; I don't see much .*

This is why it works out in Elm -- because people don't use it much.

-- 
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] Package Stutter

[Robert Engels]

I know everyone hates it when I reference java but it has had dot imports at 
the package level since day one. I won’t repeat why that matters. It’s never 
been a problem.

I don’t think I ever heard someone complain it was a problem in working in 
Java, why is it such a problem in Go? I’m suspecting it’s because people’s 
packages are too large in scope so they end importing tons of external 
packages. It’s a structure problem not a language feature problem. 

> On Dec 1, 2018, at 11:08 PM, Ian Denhardt  wrote:
> 
> Quoting Robert Engels (2018-12-01 22:25:06)
> 
>> The way to fix it though it just to use dot imports, and encourage it!
>> The only time dot imports don't work is when there isn't package
>> stutter. Seems like a no brainer and you get the best of both worlds.
> 
> My experience in every language I've worked with that has an equivalent
> of dot imports has been: this is more trouble than it's worth. It hurts
> readability of large codebases more than any other single language
> feature I can think of, and this has been my experience in everything
> from Python to Haskell.
> 
> It is sometimes nice for DSLs -- Elm has an Html module that just
> defines a function per html element, and folks usually "dot import"
> that whole module. But they basically never "dot import" *anything*
> else, and doing it in the general case is similarly discouraged. In
> languages where I've seen *common* use of it, I've come to the
> conclusion that it basically doesn't scale beyond one package, which
> has to be something that everyone in the language community knows well.
> In Elm it's Html. In Go it's the set of built-in identifiers. That's all
> we get.
> 
> ---
> 
> There really is something special about a package's "main" type here
> (when it has one) that makes the stutter a bit hard to work around
> sometimes.  It's a bit unfortunate to have to write context.Context, but
> nothing *else* in the context package has this problem. Much of the
> OCaml community has gone with the convention of just calling the type
> 't' and using the module name to distinguish, and it works pretty well.
> 
> In Elm you see a lot of this:
> 
>import Json.Decoder exposing (Decoder)
> 
> ..which imports the Decoder type from that module unqualified, and
> leaves the rest qualified.
> 
> I find it a bit unfortunate that the stuttery approach to naming primary
> times has ended up being the norm in Go, but I do think idiom is worth
> something; doing pkg.T is a little surprising to me when reading Go
> code, even though it isn't when reading OCaml.
> 
>>   People say, it makes things less clear, and I counter that variable
>>   inference is far worse and it's done for the sake of less verbosity,
>>   and people love it...
> 
> I don't think we're going to agree on this point any time soon, so I'll
> just say: this does not square with my own experience.
> 
> -- 
> 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] Package Stutter

[Ian Denhardt]

Quoting Robert Engels (2018-12-01 22:25:06)

> The way to fix it though it just to use dot imports, and encourage it!
> The only time dot imports don't work is when there isn't package
> stutter. Seems like a no brainer and you get the best of both worlds.

My experience in every language I've worked with that has an equivalent
of dot imports has been: this is more trouble than it's worth. It hurts
readability of large codebases more than any other single language
feature I can think of, and this has been my experience in everything
from Python to Haskell.

It is sometimes nice for DSLs -- Elm has an Html module that just
defines a function per html element, and folks usually "dot import"
that whole module. But they basically never "dot import" *anything*
else, and doing it in the general case is similarly discouraged. In
languages where I've seen *common* use of it, I've come to the
conclusion that it basically doesn't scale beyond one package, which
has to be something that everyone in the language community knows well.
In Elm it's Html. In Go it's the set of built-in identifiers. That's all
we get.

---

There really is something special about a package's "main" type here
(when it has one) that makes the stutter a bit hard to work around
sometimes.  It's a bit unfortunate to have to write context.Context, but
nothing *else* in the context package has this problem. Much of the
OCaml community has gone with the convention of just calling the type
't' and using the module name to distinguish, and it works pretty well.

In Elm you see a lot of this:

import Json.Decoder exposing (Decoder)

..which imports the Decoder type from that module unqualified, and
leaves the rest qualified.

I find it a bit unfortunate that the stuttery approach to naming primary
times has ended up being the norm in Go, but I do think idiom is worth
something; doing pkg.T is a little surprising to me when reading Go
code, even though it isn't when reading OCaml.

>People say, it makes things less clear, and I counter that variable
>inference is far worse and it's done for the sake of less verbosity,
>and people love it...

I don't think we're going to agree on this point any time soon, so I'll
just say: this does not square with my own experience.

-- 
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] Package Stutter

[Bakul Shah]

I would've probably chosen context.State or context.Type;
but to be frank "Context" always seemed a bit too generic
to me. Looking at its definition it seems like something
to carry a bunch of random stuff. Sort of like a knapsack!

Naming is not easy. As usual Dijkstra has something
interesting to say about this topic!
https://www.cs.utexas.edu/users/EWD/ewd09xx/EWD958.PDF

> On Dec 1, 2018, at 6:51 PM, Sameer Ajmani  wrote:
> 
> For what it's worth, we considered various ways to shorten context.Context 
> before releasing it as open source. The obvious choice would be context.C, 
> but I was concerned this would encourage people to name their context 
> variables c, which conflicts with the common short name for channel 
> variables. Since we typically use the short name ctx, we also considered the 
> type name context.Ctx, but this seemed too arbitrary. We went with 
> context.Context because it's clear and doesn't introduce any unnecessary 
> confusion.
> S
> On Sat, Dec 1, 2018 at 1:25 PM Robert Engels  wrote:
> I agree. You need to understand the expected usage patterns (and possibly 
> other external and internal constraints) before you can claim that any design 
> “needs change”. 
> 
> On Dec 1, 2018, at 12:18 PM, Bakul Shah  wrote:
> 
>> Reducing stutter.Stutter is a good thing. But coming up with meaningful
>> names ThatDontTakeHalfALineAndReduceCodeDensity is often quite
>> hard (but ultimately rewarding as it forces you to think more clearly).
>> And languages and practices evolve as people gain more experience
>> so early practices should not be seen as a model for newer code.
>> 
>> Nigel Tao mentioned fixed.Int26_6, which is much more useful as it shows
>> where the fixed point lies for this type. In my case I used currency.Type for
>> its main type, not currency.Currency. The "fixed point" may in fact depend
>> on a specific currency.
>> 
>> Bottom line: think of "reduce stutter" as a *best practice* but not a *rule*!
>> 
>>> On Dec 1, 2018, at 9:53 AM, Robert Engels  wrote:
>>> 
>>> That was my point. The earliest practitioners and language designers used 
>>> the construct extensively but now others claim it is not the way. I find it 
>>> hard to believe that in testing the original Go design the creators didn’t 
>>> think about this - which means they decided it was fine. So why the change?
>>> 
>>> On Dec 1, 2018, at 11:01 AM, Tristan Colgate  wrote:
>>> 
 In the cases of time and context, the stutters appear in a primary type 
 that is important to the package, but rarely appears directly in normal 
 API usage.
   E.g., time.Now(), context.Background().  
   Stutter is to be avoided. The package name can provide context. But 
 stutter is preferred to, e.g. time.Type, where one package largely 
 operates on one type
   I doubt there would be a peer reviewed paper on something which is 
 basically just an opinion held by the language's earliest practitioners. 
 It doesn't mean the idea does not have merit though.
 
 On Sat, 1 Dec 2018, 14:19 Robert Engels,  wrote:
 In another thread, it has been brought up that things like time.Time are 
 no good. But this format is pervasive. Even newer packages like 
 context.Context.
 
 It seems to have been this way for a long time. 
 
 It there some reasoned paper on why this is now so frowned upon?
 
 -- 
 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.

-- 
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] Package Stutter

[Robert Engels]

I think context.Context is fine, it’s weird though I’ll admit. 

The way to fix it though it just to use dot imports, and encourage it! The only 
time dot imports don’t work is when there isn’t package stutter. Seems like a 
no brainer and you get the best of both worlds. 

You have similar problems in the general case... say you are writing an image 
processing app, you are probably going to use stdlib image package and probably 
an image package in third party libraries - so you need to use import overrides 
anyway... 

Promote the use of dot for common “defined within the particular application 
scope” libraries. Most apps would probably dot import context because it is so 
pervasive. The method signatures would be far more readable when using common 
outside types as parameters, Time and Duration come to mind. 

People say, it makes things less clear, and I counter that variable inference 
is far worse and it’s done for the sake of less verbosity, and people love it...

Since Map is a common interface, using collections.Map is just silly. And if 
you had a conflicting type then you fully qualify it. 

Seems pretty simple. 


> On Dec 1, 2018, at 8:51 PM, Sameer Ajmani  wrote:
> 
> For what it's worth, we considered various ways to shorten context.Context 
> before releasing it as open source. The obvious choice would be context.C, 
> but I was concerned this would encourage people to name their context 
> variables c, which conflicts with the common short name for channel 
> variables. Since we typically use the short name ctx, we also considered the 
> type name context.Ctx, but this seemed too arbitrary. We went with 
> context.Context because it's clear and doesn't introduce any unnecessary 
> confusion.
> S
>> On Sat, Dec 1, 2018 at 1:25 PM Robert Engels  wrote:
>> I agree. You need to understand the expected usage patterns (and possibly 
>> other external and internal constraints) before you can claim that any 
>> design “needs change”. 
>> 
>>> On Dec 1, 2018, at 12:18 PM, Bakul Shah  wrote:
>>> 
>>> Reducing stutter.Stutter is a good thing. But coming up with meaningful
>>> names ThatDontTakeHalfALineAndReduceCodeDensity is often quite
>>> hard (but ultimately rewarding as it forces you to think more clearly).
>>> And languages and practices evolve as people gain more experience
>>> so early practices should not be seen as a model for newer code.
>>> 
>>> Nigel Tao mentioned fixed.Int26_6, which is much more useful as it shows
>>> where the fixed point lies for this type. In my case I used currency.Type 
>>> for
>>> its main type, not currency.Currency. The "fixed point" may in fact depend
>>> on a specific currency.
>>> 
>>> Bottom line: think of "reduce stutter" as a *best practice* but not a 
>>> *rule*!
>>> 
 On Dec 1, 2018, at 9:53 AM, Robert Engels  wrote:
 
 That was my point. The earliest practitioners and language designers used 
 the construct extensively but now others claim it is not the way. I find 
 it hard to believe that in testing the original Go design the creators 
 didn’t think about this - which means they decided it was fine. So why the 
 change?
 
> On Dec 1, 2018, at 11:01 AM, Tristan Colgate  wrote:
> 
> In the cases of time and context, the stutters appear in a primary type 
> that is important to the package, but rarely appears directly in normal 
> API usage.
>   E.g., time.Now(), context.Background().  
>   Stutter is to be avoided. The package name can provide context. But 
> stutter is preferred to, e.g. time.Type, where one package largely 
> operates on one type
>   I doubt there would be a peer reviewed paper on something which is 
> basically just an opinion held by the language's earliest practitioners. 
> It doesn't mean the idea does not have merit though.
> 
>> On Sat, 1 Dec 2018, 14:19 Robert Engels,  wrote:
>> In another thread, it has been brought up that things like time.Time are 
>> no good. But this format is pervasive. Even newer packages like 
>> context.Context.
>> 
>> It seems to have been this way for a long time. 
>> 
>> It there some reasoned paper on why this is now so frowned upon?
>> 
>> -- 
>> 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 
>> 

Re: [go-nuts] Package Stutter

[Sameer Ajmani]

For what it's worth, we considered various ways to shorten context.Context
before releasing it as open source. The obvious choice would be context.C,
but I was concerned this would encourage people to name their context
variables c, which conflicts with the common short name for channel
variables. Since we typically use the short name ctx, we also considered
the type name context.Ctx, but this seemed too arbitrary. We went with
context.Context because it's clear and doesn't introduce any unnecessary
confusion.
S
On Sat, Dec 1, 2018 at 1:25 PM Robert Engels  wrote:

> I agree. You need to understand the expected usage patterns (and possibly
> other external and internal constraints) before you can claim that any
> design “needs change”.
>
> On Dec 1, 2018, at 12:18 PM, Bakul Shah  wrote:
>
> Reducing stutter.Stutter is a good thing. But coming up with meaningful
> names ThatDontTakeHalfALineAndReduceCodeDensity is often quite
> hard (but ultimately rewarding as it forces you to think more clearly).
> And languages and practices evolve as people gain more experience
> so early practices should not be seen as a model for newer code.
>
> Nigel Tao mentioned fixed.Int26_6, which is much more useful as it shows
> where the fixed point lies for this type. In my case I used currency.Type
> for
> its main type, not currency.Currency. The "fixed point" may in fact depend
> on a specific currency.
>
> Bottom line: think of "reduce stutter" as a *best practice* but not a
> *rule*!
>
> On Dec 1, 2018, at 9:53 AM, Robert Engels  wrote:
>
> That was my point. The earliest practitioners and language designers used
> the construct extensively but now others claim it is not the way. I find it
> hard to believe that in testing the original Go design the creators didn’t
> think about this - which means they decided it was fine. So why the change?
>
> On Dec 1, 2018, at 11:01 AM, Tristan Colgate  wrote:
>
> In the cases of time and context, the stutters appear in a primary type
> that is important to the package, but rarely appears directly in normal API
> usage.
>   E.g., time.Now(), context.Background().
>   Stutter is to be avoided. The package name can provide context. But
> stutter is preferred to, e.g. time.Type, where one package largely operates
> on one type
>   I doubt there would be a peer reviewed paper on something which is
> basically just an opinion held by the language's earliest practitioners. It
> doesn't mean the idea does not have merit though.
>
> On Sat, 1 Dec 2018, 14:19 Robert Engels,  wrote:
>
>> In another thread, it has been brought up that things like time.Time are
>> no good. But this format is pervasive. Even newer packages like
>> context.Context.
>>
>> It seems to have been this way for a long time.
>>
>> It there some reasoned paper on why this is now so frowned upon?
>>
>> --
>> 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.
>

-- 
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] Package Stutter

[Robert Engels]

I agree. You need to understand the expected usage patterns (and possibly other 
external and internal constraints) before you can claim that any design “needs 
change”. 

> On Dec 1, 2018, at 12:18 PM, Bakul Shah  wrote:
> 
> Reducing stutter.Stutter is a good thing. But coming up with meaningful
> names ThatDontTakeHalfALineAndReduceCodeDensity is often quite
> hard (but ultimately rewarding as it forces you to think more clearly).
> And languages and practices evolve as people gain more experience
> so early practices should not be seen as a model for newer code.
> 
> Nigel Tao mentioned fixed.Int26_6, which is much more useful as it shows
> where the fixed point lies for this type. In my case I used currency.Type for
> its main type, not currency.Currency. The "fixed point" may in fact depend
> on a specific currency.
> 
> Bottom line: think of "reduce stutter" as a *best practice* but not a *rule*!
> 
>> On Dec 1, 2018, at 9:53 AM, Robert Engels  wrote:
>> 
>> That was my point. The earliest practitioners and language designers used 
>> the construct extensively but now others claim it is not the way. I find it 
>> hard to believe that in testing the original Go design the creators didn’t 
>> think about this - which means they decided it was fine. So why the change?
>> 
>>> On Dec 1, 2018, at 11:01 AM, Tristan Colgate  wrote:
>>> 
>>> In the cases of time and context, the stutters appear in a primary type 
>>> that is important to the package, but rarely appears directly in normal API 
>>> usage.
>>>   E.g., time.Now(), context.Background().  
>>>   Stutter is to be avoided. The package name can provide context. But 
>>> stutter is preferred to, e.g. time.Type, where one package largely operates 
>>> on one type
>>>   I doubt there would be a peer reviewed paper on something which is 
>>> basically just an opinion held by the language's earliest practitioners. It 
>>> doesn't mean the idea does not have merit though.
>>> 
 On Sat, 1 Dec 2018, 14:19 Robert Engels,  wrote:
 In another thread, it has been brought up that things like time.Time are 
 no good. But this format is pervasive. Even newer packages like 
 context.Context.
 
 It seems to have been this way for a long time. 
 
 It there some reasoned paper on why this is now so frowned upon?
 
 -- 
 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] Package Stutter

[Bakul Shah]

Reducing stutter.Stutter is a good thing. But coming up with meaningful
names ThatDontTakeHalfALineAndReduceCodeDensity is often quite
hard (but ultimately rewarding as it forces you to think more clearly).
And languages and practices evolve as people gain more experience
so early practices should not be seen as a model for newer code.

Nigel Tao mentioned fixed.Int26_6, which is much more useful as it shows
where the fixed point lies for this type. In my case I used currency.Type for
its main type, not currency.Currency. The "fixed point" may in fact depend
on a specific currency.

Bottom line: think of "reduce stutter" as a *best practice* but not a *rule*!

> On Dec 1, 2018, at 9:53 AM, Robert Engels  wrote:
> 
> That was my point. The earliest practitioners and language designers used the 
> construct extensively but now others claim it is not the way. I find it hard 
> to believe that in testing the original Go design the creators didn’t think 
> about this - which means they decided it was fine. So why the change?
> 
> On Dec 1, 2018, at 11:01 AM, Tristan Colgate  > wrote:
> 
>> In the cases of time and context, the stutters appear in a primary type that 
>> is important to the package, but rarely appears directly in normal API usage.
>>   E.g., time.Now(), context.Background().  
>>   Stutter is to be avoided. The package name can provide context. But 
>> stutter is preferred to, e.g. time.Type, where one package largely operates 
>> on one type
>>   I doubt there would be a peer reviewed paper on something which is 
>> basically just an opinion held by the language's earliest practitioners. It 
>> doesn't mean the idea does not have merit though.
>> 
>> On Sat, 1 Dec 2018, 14:19 Robert Engels, > > wrote:
>> In another thread, it has been brought up that things like time.Time are no 
>> good. But this format is pervasive. Even newer packages like context.Context.
>> 
>> It seems to have been this way for a long time. 
>> 
>> It there some reasoned paper on why this is now so frowned upon?
>> 
>> -- 
>> 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] Package Stutter

[Robert Engels]

I can understand that and it seems reasonable but if I’m writing a new Ring 
“class” and it supports both a standard and a concurrent version, I’m probably 
not going to create two packages. I would create one package named ring and 
have NewRing and NewSyncRing. Which is what I and I think you are saying, each 
case is unique and having a “rule” is too restrictive. 

Good software design is applying patterns reasonably not as a matter of rules 
IMO. 

> On Dec 1, 2018, at 11:57 AM, Ian Lance Taylor  wrote:
> 
>> On Sat, Dec 1, 2018 at 9:53 AM Robert Engels  wrote:
>> 
>> That was my point. The earliest practitioners and language designers used 
>> the construct extensively but now others claim it is not the way. I find it 
>> hard to believe that in testing the original Go design the creators didn’t 
>> think about this - which means they decided it was fine. So why the change?
> 
> I don't think there is any hard and fast rule here.  Each choice needs
> to be made in the appropriate context.  We use testing.T, not
> testing.Testing.  We use time.Time, not time.T.  The goal should
> always be clarity for the reader.
> 
> Effective Go, which was written very early on in the development of
> the language, has this to say:
> 
> "The importer of a package will use the name to refer to its contents,
> so exported names in the package can use that fact to avoid stutter.
> (Don't use the import . notation, which can simplify tests that must
> run outside the package they are testing, but should otherwise be
> avoided.) For instance, the buffered reader type in the bufio package
> is called Reader, not BufReader, because users see it as bufio.Reader,
> which is a clear, concise name. Moreover, because imported entities
> are always addressed with their package name, bufio.Reader does not
> conflict with io.Reader. Similarly, the function to make new instances
> of ring.Ring—which is the definition of a constructor in Go—would
> normally be called NewRing, but since Ring is the only type exported
> by the package, and since the package is called ring, it's called just
> New, which clients of the package see as ring.New. Use the package
> structure to help you choose good names."
> 
> Ian
> 
>> On Dec 1, 2018, at 11:01 AM, Tristan Colgate  wrote:
>> 
>> In the cases of time and context, the stutters appear in a primary type that 
>> is important to the package, but rarely appears directly in normal API usage.
>>  E.g., time.Now(), context.Background().
>>  Stutter is to be avoided. The package name can provide context. But stutter 
>> is preferred to, e.g. time.Type, where one package largely operates on one 
>> type
>>  I doubt there would be a peer reviewed paper on something which is 
>> basically just an opinion held by the language's earliest practitioners. It 
>> doesn't mean the idea does not have merit though.
>> 
>>> On Sat, 1 Dec 2018, 14:19 Robert Engels,  wrote:
>>> 
>>> In another thread, it has been brought up that things like time.Time are no 
>>> good. But this format is pervasive. Even newer packages like 
>>> context.Context.
>>> 
>>> It seems to have been this way for a long time.
>>> 
>>> It there some reasoned paper on why this is now so frowned upon?
>>> 
>>> --
>>> 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] Package Stutter

[Ian Lance Taylor]

On Sat, Dec 1, 2018 at 9:53 AM Robert Engels  wrote:
>
> That was my point. The earliest practitioners and language designers used the 
> construct extensively but now others claim it is not the way. I find it hard 
> to believe that in testing the original Go design the creators didn’t think 
> about this - which means they decided it was fine. So why the change?

I don't think there is any hard and fast rule here.  Each choice needs
to be made in the appropriate context.  We use testing.T, not
testing.Testing.  We use time.Time, not time.T.  The goal should
always be clarity for the reader.

Effective Go, which was written very early on in the development of
the language, has this to say:

"The importer of a package will use the name to refer to its contents,
so exported names in the package can use that fact to avoid stutter.
(Don't use the import . notation, which can simplify tests that must
run outside the package they are testing, but should otherwise be
avoided.) For instance, the buffered reader type in the bufio package
is called Reader, not BufReader, because users see it as bufio.Reader,
which is a clear, concise name. Moreover, because imported entities
are always addressed with their package name, bufio.Reader does not
conflict with io.Reader. Similarly, the function to make new instances
of ring.Ring—which is the definition of a constructor in Go—would
normally be called NewRing, but since Ring is the only type exported
by the package, and since the package is called ring, it's called just
New, which clients of the package see as ring.New. Use the package
structure to help you choose good names."

Ian

> On Dec 1, 2018, at 11:01 AM, Tristan Colgate  wrote:
>
> In the cases of time and context, the stutters appear in a primary type that 
> is important to the package, but rarely appears directly in normal API usage.
>   E.g., time.Now(), context.Background().
>   Stutter is to be avoided. The package name can provide context. But stutter 
> is preferred to, e.g. time.Type, where one package largely operates on one 
> type
>   I doubt there would be a peer reviewed paper on something which is 
> basically just an opinion held by the language's earliest practitioners. It 
> doesn't mean the idea does not have merit though.
>
> On Sat, 1 Dec 2018, 14:19 Robert Engels,  wrote:
>>
>> In another thread, it has been brought up that things like time.Time are no 
>> good. But this format is pervasive. Even newer packages like context.Context.
>>
>> It seems to have been this way for a long time.
>>
>> It there some reasoned paper on why this is now so frowned upon?
>>
>> --
>> 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] Package Stutter

[Robert Engels]

That was my point. The earliest practitioners and language designers used the 
construct extensively but now others claim it is not the way. I find it hard to 
believe that in testing the original Go design the creators didn’t think about 
this - which means they decided it was fine. So why the change?

> On Dec 1, 2018, at 11:01 AM, Tristan Colgate  wrote:
> 
> In the cases of time and context, the stutters appear in a primary type that 
> is important to the package, but rarely appears directly in normal API usage.
>   E.g., time.Now(), context.Background().  
>   Stutter is to be avoided. The package name can provide context. But stutter 
> is preferred to, e.g. time.Type, where one package largely operates on one 
> type
>   I doubt there would be a peer reviewed paper on something which is 
> basically just an opinion held by the language's earliest practitioners. It 
> doesn't mean the idea does not have merit though.
> 
>> On Sat, 1 Dec 2018, 14:19 Robert Engels,  wrote:
>> In another thread, it has been brought up that things like time.Time are no 
>> good. But this format is pervasive. Even newer packages like context.Context.
>> 
>> It seems to have been this way for a long time. 
>> 
>> It there some reasoned paper on why this is now so frowned upon?
>> 
>> -- 
>> 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] Package Stutter

[Tristan Colgate]

In the cases of time and context, the stutters appear in a primary type
that is important to the package, but rarely appears directly in normal API
usage.
  E.g., time.Now(), context.Background().
  Stutter is to be avoided. The package name can provide context. But
stutter is preferred to, e.g. time.Type, where one package largely operates
on one type
  I doubt there would be a peer reviewed paper on something which is
basically just an opinion held by the language's earliest practitioners. It
doesn't mean the idea does not have merit though.

On Sat, 1 Dec 2018, 14:19 Robert Engels,  wrote:

> In another thread, it has been brought up that things like time.Time are
> no good. But this format is pervasive. Even newer packages like
> context.Context.
>
> It seems to have been this way for a long time.
>
> It there some reasoned paper on why this is now so frowned upon?
>
> --
> 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.