Re: [go-nuts] [ANN] fixed point math library

[Michael Jones]

Which reminds me...these kinds of name changes deserve a thread/list in the
Go2 proposals

On Sat, Dec 1, 2018 at 12:17 AM Anthony Martin  wrote:

> Nigel Tao  once said:
> > Well, there's already context.Context, hash.Hash, image.Image and
> > time.Time in the standard library.
>
> All of which are not great. Better names are context.Frame,
> hash.Function, raster.Image, and time.Instant.
>
>   Anthony
>
> --
> 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.
>


-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: pointer dereference optimization in loops

[Anthony Martin]

Mark Volkmann  once said:
> Suppose myPtr is a pointer and I write code like this:
> 
> for _, v := range values {
> fmt.Printf("%v %v\n", *myPtr, v)
> }
> 
> Will the Go compiler optimize the pointer dereference so it doesn't happen
> in every loop iteration? If not, is it common practice to do that outside
> the loop like this?

The comments on https://github.com/golang/go/issues/15635 may be of
particular interest.

  Anthony

-- 
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] [ANN] fixed point math library

[Anthony Martin]

Nigel Tao  once said:
> Well, there's already context.Context, hash.Hash, image.Image and
> time.Time in the standard library.

All of which are not great. Better names are context.Frame,
hash.Function, raster.Image, and time.Instant.

  Anthony

-- 
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] [ANN] fixed point math library

[Dan Kortschak]

Very nice.

On Sat, 2018-12-01 at 00:16 -0800, Anthony Martin wrote:
> Nigel Tao  once said:
> > 
> > Well, there's already context.Context, hash.Hash, image.Image and
> > time.Time in the standard library.
> All of which are not great. Better names are context.Frame,
> hash.Function, raster.Image, and time.Instant.
> 
>   Anthony
> 

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

[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

[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

[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

[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] Rethink possibility to make circular imports

['Axel Wagner' via golang-nuts]

Anecdote: A (large) Java project I worked on ran into trouble with cyclic
dependencies so often, that they started introducing conventions like
"classes under directory X are not allowed to import classes under
directory Y (but vice-versa)", effectively emulating Go's prohibition of
cyclic imports by convention. Every once in a while, an import violating
that convention slipped through, causing issues.

Go's prohibition of cyclic imports forces you to write your application as
a tower of abstractions, that can only traversed downwards, not upwards.
That's, in general, considered a good design principle in software
engineering - Go just makes it compiler-checked :) (on a side-note, that's
why I'm slightly uncomfortable with the notion of using interfaces to
"break import cycles" - because the functional dependency is still there,
it's just no longer visible to the compiler. But that's kinda off-topic I
guess).

On Sun, Dec 2, 2018 at 1:31 AM David Collier-Brown 
wrote:

> I find the same, but eventually I come up with a way to clarify. Just *Not
> Real Soon* (;-))
>
>
 --
> 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] Rethink possibility to make circular imports

[David Collier-Brown]

I find the same, but eventually I come up with a way to clarify. Just *Not 
Real Soon* (;-))


>>>

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

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

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]

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

[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

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

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

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

[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

[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] [ANN] fixed point math library

[Robert Engels]

I disagree with a few of those, but the simplest example is image. There still 
needs to be an image.Image interface for methods common to all image types. 
Then sub packages for raster and vector (others?)  There are too many different 
image types so you end up a multitude of packages and since package names need 
to be short you lose a lot of information. An easy example is fractal. There 
are fractal images do you would have fractal.Image but most people seeing a 
package called fractal would assume it handle fractals 

Personally I would like to look at the documentation for the image package to 
quickly see all of the supported types. 

Thus is why having a “rule” is tough to do in practice. 



> On Dec 1, 2018, at 8:22 AM, Michael Jones  wrote:
> 
> I'll also add that personally I saw a lot of "change this" commentary with 
> rather little "thank you." That was not in the best spirit of what (at at 
> least I think) it should be. It's always good to act on ideas, build 
> solutions, and share results. It would be great if everyone always started 
> with that. You deserve it as does your code.
> 
> Thank you!
> Michael
> 
>> On Sat, Dec 1, 2018 at 6:17 AM Michael Jones  wrote:
>> I can see why you're feeling that. My sense is that what causes flare-ups is 
>> when people (universally rather than just here) get the feeling that the 
>> discussion is becoming personal rather than technical. Go is lots of 
>> people's work / tool / job / fun / etc., so passions may be strong, but I've 
>> never seen any tendency to be angry and protective about people raising 
>> issues with poor choices. What does come up is the desire for examples, 
>> use-cases, and other kinds of supporting information so that the 
>> conversation moves from "i feel that" ==> "in these situations" ==> "a 
>> workable resolution" ==> ... ==> "X seems the best way forward after much 
>> analysis." That made go great so far, and the conversations generally 
>> collegial.
>> 
>>> On Sat, Dec 1, 2018 at 6:00 AM Robert Engels  wrote:
>>> This is a problem with it seems more than a few in this community. Someone 
>>> makes a criticism of an idea, backs it up, and is treated in a childish 
>>> manner because it doesn’t go along with dominate opinions of the 
>>> controllers of the group think. Not good IMO. 
>>> 
 On Dec 1, 2018, at 7:48 AM, Jan Mercl <0xj...@gmail.com> wrote:
 
 On Sat, Dec 1, 2018 at 9:47 AM Dan Kortschak  wrote:
 
 > Very nice.
 
 Indeed.
 
 -- 
 -j
 
 -- 
 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.
>> 
>> 
>> -- 
>> Michael T. Jones
>> michael.jo...@gmail.com
> 
> 
> -- 
> Michael T. Jones
> michael.jo...@gmail.com

-- 
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] [ANN] fixed point math library

[Michael Jones]

I need to do a thorough summary, but as an example of things that could
usefully change (perhaps) for improved coherence and excellence in Go2
through naming and simple rewrites, consider the image package.

1. The name of the package (fine always it seem, but in some cases maybe a
change would help)
2. The name of functions and methods (fine generally, but a few oddities
exist here and there)
3. The approach to special/exceptional actions. Image has a glaring issue
here, described below.

The way options/defaults/configurations are set varies between JPEG, PNG,
and TIFF such that in one case you set an option via a method call, one via
a "constructor" like list, one via a configuration struct that you pass in,
and one voa a config struct that you call methods against.

Any of these is fine to me, but having a variety of them is testament to
the addition of image format support at different times by different hands
and it would seem sad if Go17 was still this way. Instead, now that
examples exist for each style, why not pick one of them (any one!) and
convert the others to the same scheme. I know itr would be arbitrary
breakage now, but that's paying forward for technical debt. When 1M Go
developers becomes 10M, we'll have at 9M happy campers who never realized
it was "wild" (disharmonious, unmutual) in the old days.


4. The approach to error labeling and categorization.
5. The "meta-ness" of the API. Hard to find the right way to say this, but
for example, the filesystem APIs presume you're using the system native
filesystem--naturally. But if you need to do all the same work but in a ZIP
file, or in a custom binary blob with a file system inside, that ends up
being a parallel construct rather than being able to say os.Open is the
null case of MyFileSystem.Open with everything else in the filesystem API
there naturally, or settabble in some way.

Not arguing for any of these points here, just sharing that name polishing,
unjustified variety in same-notion aspects of the API, and "only now do we
realize that" generalizations all seem perfect subjects for careful review
as part of the Go2 process. I'm in favor of the thought you're raising.
Also, on the name front, it is not only the "package.Function()" that
developers see, but hopefully more often it is variable.Method() and in
case any package-name-based stuttering is gone. This is a subtle motivation
to look for designs/refactorings that are heavy on methods on package
types. (well...I think it is. there may not be consensus on that)

Michael

On Sat, Dec 1, 2018 at 6:52 AM Robert Engels  wrote:

> I disagree with a few of those, but the simplest example is image. There
> still needs to be an image.Image interface for methods common to all image
> types. Then sub packages for raster and vector (others?)  There are too
> many different image types so you end up a multitude of packages and since
> package names need to be short you lose a lot of information. An easy
> example is fractal. There are fractal images do you would have
> fractal.Image but most people seeing a package called fractal would assume
> it handle fractals
>
> Personally I would like to look at the documentation for the image package
> to quickly see all of the supported types.
>
> Thus is why having a “rule” is tough to do in practice.
>
>
>
> On Dec 1, 2018, at 8:22 AM, Michael Jones  wrote:
>
> I'll also add that personally I saw a lot of "change this" commentary with
> rather little "thank you." That was not in the best spirit of what (at at
> least I think) it should be. It's always good to act on ideas, build
> solutions, and share results. It would be great if everyone always started
> with that. You deserve it as does your code.
>
> Thank you!
> Michael
>
> On Sat, Dec 1, 2018 at 6:17 AM Michael Jones 
> wrote:
>
>> I can see why you're feeling that. My sense is that what causes flare-ups
>> is when people (universally rather than just here) get the feeling that the
>> discussion is becoming personal rather than technical. Go is lots of
>> people's work / tool / job / fun / etc., so passions may be strong, but
>> I've never seen any tendency to be angry and protective about people
>> raising issues with poor choices. What does come up is the desire for
>> examples, use-cases, and other kinds of supporting information so that the
>> conversation moves from "i feel that" ==> "in these situations" ==> "a
>> workable resolution" ==> ... ==> "X seems the best way forward after much
>> analysis." That made go great so far, and the conversations generally
>> collegial.
>>
>> On Sat, Dec 1, 2018 at 6:00 AM Robert Engels 
>> wrote:
>>
>>> This is a problem with it seems more than a few in this community.
>>> Someone makes a criticism of an idea, backs it up, and is treated in a
>>> childish manner because it doesn’t go along with dominate opinions of the
>>> controllers of the group think. Not good IMO.
>>>
>>> On Dec 1, 2018, at 7:48 AM, Jan Mercl <0xj...@gmail.com> wrote:
>>>

Re: [go-nuts] [ANN] fixed point math library

[Robert Engels]

hash.Function? Then you need print.Function. So soon enough there will be a 
1000 interfaces named Function that have nothing to do with hashing or printing 
because everything can be decomposed that way. 

context.Frame? Now you’re just being silly. You might as well use 
context.Instance or even Function...

This an issue because of the reluctance to properly support the dot import (or 
something like it). Then you would just have Context, which for core types is 
what you want. If you have a specialized Context then it should be fully 
qualified. 

It’s comforting to know that Go will end with 1.x because 2.0 is going to be 
designed by committee and is going to stink. Too many people talking just to 
hear themselves. 

Forget the “rules” and focus on writing software that is easy to read, write 
and maintain. 

You’ll know it when you see it. APIs are hard. Leave it to the practical 
professionals. 

> On Dec 1, 2018, at 2:46 AM, Dan Kortschak  wrote:
> 
> Very nice.
> 
>> On Sat, 2018-12-01 at 00:16 -0800, Anthony Martin wrote:
>> Nigel Tao  once said:
>>> 
>>> Well, there's already context.Context, hash.Hash, image.Image and
>>> time.Time in the standard library.
>> All of which are not great. Better names are context.Frame,
>> hash.Function, raster.Image, and time.Instant.
>> 
>>   Anthony
>> 
> 
> -- 
> 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] [ANN] fixed point math library

[Robert Engels]

And while we’re at it, take a closer look at the hash package 
https://golang.org/pkg/hash/#Hash

Especially the example and the doc surrounding it. 

Why doesn’t Hash “extend” the binary marshall interfaces? Why the need to cast 
if the documentation says it does?

There are a lot of low hanging fruit that should be corrected in Go 2 that 
should be easily agreed upon. 

> On Dec 1, 2018, at 6:53 AM, Robert Engels  wrote:
> 
> hash.Function? Then you need print.Function. So soon enough there will be a 
> 1000 interfaces named Function that have nothing to do with hashing or 
> printing because everything can be decomposed that way. 
> 
> context.Frame? Now you’re just being silly. You might as well use 
> context.Instance or even Function...
> 
> This an issue because of the reluctance to properly support the dot import 
> (or something like it). Then you would just have Context, which for core 
> types is what you want. If you have a specialized Context then it should be 
> fully qualified. 
> 
> It’s comforting to know that Go will end with 1.x because 2.0 is going to be 
> designed by committee and is going to stink. Too many people talking just to 
> hear themselves. 
> 
> Forget the “rules” and focus on writing software that is easy to read, write 
> and maintain. 
> 
> You’ll know it when you see it. APIs are hard. Leave it to the practical 
> professionals. 
> 
>> On Dec 1, 2018, at 2:46 AM, Dan Kortschak  wrote:
>> 
>> Very nice.
>> 
> On Sat, 2018-12-01 at 00:16 -0800, Anthony Martin wrote:
 Nigel Tao  once said:
 
 Well, there's already context.Context, hash.Hash, image.Image and
 time.Time in the standard library.
>>> All of which are not great. Better names are context.Frame,
>>> hash.Function, raster.Image, and time.Instant.
>>> 
>>>  Anthony
>> 
>> -- 
>> 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] [ANN] fixed point math library

[Robert Engels]

And let’s keep going, the sha256 package handles sha256 and sha224 ? Huh?

And the NewX return hash.Hash rather than the concrete type - which would be 
fine except for the implicit Marshall interfaces. If they returned the concrete 
type I could have my own interface HashWithMarshall it could be assigned to and 
compiled time type checked. 

Just face it. There are a lot of issues to be address in Go. There are 
currently 4000 open issues. 

Maybe Go 2 should be tabled and some of the lower hanging fruit attacked, 
especially issues that can be address without breaking backwards compatibility. 

> On Dec 1, 2018, at 7:04 AM, Robert Engels  wrote:
> 
> And while we’re at it, take a closer look at the hash package 
> https://golang.org/pkg/hash/#Hash
> 
> Especially the example and the doc surrounding it. 
> 
> Why doesn’t Hash “extend” the binary marshall interfaces? Why the need to 
> cast if the documentation says it does?
> 
> There are a lot of low hanging fruit that should be corrected in Go 2 that 
> should be easily agreed upon. 
> 
>> On Dec 1, 2018, at 6:53 AM, Robert Engels  wrote:
>> 
>> hash.Function? Then you need print.Function. So soon enough there will be a 
>> 1000 interfaces named Function that have nothing to do with hashing or 
>> printing because everything can be decomposed that way. 
>> 
>> context.Frame? Now you’re just being silly. You might as well use 
>> context.Instance or even Function...
>> 
>> This an issue because of the reluctance to properly support the dot import 
>> (or something like it). Then you would just have Context, which for core 
>> types is what you want. If you have a specialized Context then it should be 
>> fully qualified. 
>> 
>> It’s comforting to know that Go will end with 1.x because 2.0 is going to be 
>> designed by committee and is going to stink. Too many people talking just to 
>> hear themselves. 
>> 
>> Forget the “rules” and focus on writing software that is easy to read, write 
>> and maintain. 
>> 
>> You’ll know it when you see it. APIs are hard. Leave it to the practical 
>> professionals. 
>> 
>>> On Dec 1, 2018, at 2:46 AM, Dan Kortschak  wrote:
>>> 
>>> Very nice.
>>> 
> On Sat, 2018-12-01 at 00:16 -0800, Anthony Martin wrote:
> Nigel Tao  once said:
> 
> Well, there's already context.Context, hash.Hash, image.Image and
> time.Time in the standard library.
 All of which are not great. Better names are context.Frame,
 hash.Function, raster.Image, and time.Instant.
 
  Anthony
 
>>> 
>>> -- 
>>> 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.

[go-nuts] Package Stutter

[Robert Engels]

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.

Re: [go-nuts] [ANN] fixed point math library

[Jan Mercl]

On Sat, Dec 1, 2018 at 9:47 AM Dan Kortschak  wrote:

> Very nice.

Indeed .

-- 

-j

-- 
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] [ANN] fixed point math library

[Robert Engels]

This is a problem with it seems more than a few in this community. Someone 
makes a criticism of an idea, backs it up, and is treated in a childish manner 
because it doesn’t go along with dominate opinions of the controllers of the 
group think. Not good IMO. 

> On Dec 1, 2018, at 7:48 AM, Jan Mercl <0xj...@gmail.com> wrote:
> 
> On Sat, Dec 1, 2018 at 9:47 AM Dan Kortschak  wrote:
> 
> > Very nice.
> 
> Indeed.
> 
> -- 
> -j
> 
> -- 
> 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] [ANN] fixed point math library

[Robert Engels]

Sorry, more than few is too many. Few is more appropriate.

And before this goes farther. It was a thread I started to announce a project 
some might find useful or interesting. 

It was hijacked by the powers and turned into something else. 

It wasn’t the point, nor what I wanted. 

> On Dec 1, 2018, at 8:00 AM, Robert Engels  wrote:
> 
> This is a problem with it seems more than a few in this community. Someone 
> makes a criticism of an idea, backs it up, and is treated in a childish 
> manner because it doesn’t go along with dominate opinions of the controllers 
> of the group think. Not good IMO. 
> 
>> On Dec 1, 2018, at 7:48 AM, Jan Mercl <0xj...@gmail.com> wrote:
>> 
>> On Sat, Dec 1, 2018 at 9:47 AM Dan Kortschak  wrote:
>> 
>> > Very nice.
>> 
>> Indeed.
>> 
>> -- 
>> -j
>> 
>> -- 
>> 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] [ANN] fixed point math library

[Anthony Martin]

A hash function is a mathematical construction.
A raster image is a type of graphical representation.
A time instant is a single point in a duration.

All of these are clear as can be.

I'll give you "context frame". It is a bit wonky.
A better phrase is out there somewhere. Scope,
environment, etc. could work but it also must
convey be carried or passed around.

We have lots of English words. Why not use them?

  Anthony

-- 
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] how to build golang program with a lower kernel requirement?

[Janne Snabb]

You are somehow confused. The kernel version requirement of some 
particular glibc version is not relevant. There is no problem. It works. 
See https://github.com/golang/go/wiki/MinimumRequirements for kernel 
version requirements.


Hope this helps,

Janne Snabb
sn...@epipe.com

On 30/11/2018 07.36, hui zhang wrote:
I build golang programe on ubuntu 18.04, try to run it on ubuntu 16.04 
, it hint "kernal too old"


ldd --version ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27 #ubuntu 18.04 ldd 
(Ubuntu GLIBC 2.23-3ubuntu1) 2.23 #ubuntu 16.04
glibc 2.24 above requires kernel 3.2 minimum glibc 2.23 requires 
kernel 2.6.32. minimum #ubuntu 16.04


Q1:
how to build golang program with a lower kernel requirement?

Q2:
on the other hand
if I build golang program on ubuntu 16.04 ,  can it run on ubuntu 18.04
--
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] [ANN] fixed point math library

[Michael Jones]

I can see why you're feeling that. My sense is that what causes flare-ups
is when people (universally rather than just here) get the feeling that the
discussion is becoming personal rather than technical. Go is lots of
people's work / tool / job / fun / etc., so passions may be strong, but
I've never seen any tendency to be angry and protective about people
raising issues with poor choices. What does come up is the desire for
examples, use-cases, and other kinds of supporting information so that the
conversation moves from "i feel that" ==> "in these situations" ==> "a
workable resolution" ==> ... ==> "X seems the best way forward after much
analysis." That made go great so far, and the conversations generally
collegial.

On Sat, Dec 1, 2018 at 6:00 AM Robert Engels  wrote:

> This is a problem with it seems more than a few in this community. Someone
> makes a criticism of an idea, backs it up, and is treated in a childish
> manner because it doesn’t go along with dominate opinions of the
> controllers of the group think. Not good IMO.
>
> On Dec 1, 2018, at 7:48 AM, Jan Mercl <0xj...@gmail.com> wrote:
>
> On Sat, Dec 1, 2018 at 9:47 AM Dan Kortschak  wrote:
>
> > Very nice.
>
> Indeed .
>
> --
>
> -j
>
> --
> 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.
>


-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
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] [ANN] fixed point math library

[Michael Jones]

I'll also add that personally I saw a lot of "change this" commentary with
rather little "thank you." That was not in the best spirit of what (at at
least I think) it should be. It's always good to act on ideas, build
solutions, and share results. It would be great if everyone always started
with that. You deserve it as does your code.

Thank you!
Michael

On Sat, Dec 1, 2018 at 6:17 AM Michael Jones 
wrote:

> I can see why you're feeling that. My sense is that what causes flare-ups
> is when people (universally rather than just here) get the feeling that the
> discussion is becoming personal rather than technical. Go is lots of
> people's work / tool / job / fun / etc., so passions may be strong, but
> I've never seen any tendency to be angry and protective about people
> raising issues with poor choices. What does come up is the desire for
> examples, use-cases, and other kinds of supporting information so that the
> conversation moves from "i feel that" ==> "in these situations" ==> "a
> workable resolution" ==> ... ==> "X seems the best way forward after much
> analysis." That made go great so far, and the conversations generally
> collegial.
>
> On Sat, Dec 1, 2018 at 6:00 AM Robert Engels 
> wrote:
>
>> This is a problem with it seems more than a few in this community.
>> Someone makes a criticism of an idea, backs it up, and is treated in a
>> childish manner because it doesn’t go along with dominate opinions of the
>> controllers of the group think. Not good IMO.
>>
>> On Dec 1, 2018, at 7:48 AM, Jan Mercl <0xj...@gmail.com> wrote:
>>
>> On Sat, Dec 1, 2018 at 9:47 AM Dan Kortschak  wrote:
>>
>> > Very nice.
>>
>> Indeed 
>> .
>>
>> --
>>
>> -j
>>
>> --
>> 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.
>>
>
>
> --
>
> *Michael T. jonesmichael.jo...@gmail.com *
>


-- 

*Michael T. jonesmichael.jo...@gmail.com *

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

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

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

[go-nuts] convert *byte to []byte

[leeoxiang]

Hi:

I am using swig wrap a c++ module , the generated go code is like this:

type  MediaFrame interface {
 GetLength()  uint   
 GetData()  (*byte)
}

I want to convert the *byte  to []byte,  How to do this?

-- 
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] [ANN] fixed point math library

[Ian Lance Taylor]

Please stay polite, and please follow the code of conduct
(https://golang.org/conduct).  Thanks.

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

[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

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

[go-nuts] convert *byte to []byte

[Tamás Gulácsi]

C.GoBytes

-- 
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] GoAWK: an AWK interpreter written in Go

[Ben Hoyt]

> I wonder if it makes sense, to expose more of the interpreter to go.
> E.g.: register a user function or add an action written in go.
>

I had thought about this before, but your comment made me want to try it.
It wasn't actually that hard, so I've added backwards-compatible support
for this now (GoAWK v1.1.0). It works kind of like Funcs() in text/template
or html/template.

You can pass in your Go functions as a map[string]interface{}, and as long
as they take and return bools, numbers, or strings (or []byte) it'll use
reflection to do all the hard work for you. It also supports variadic
functions. Functions defined in AWK with "function foo" take precedence
over Go functions passed in via Funcs (I did this so that passing in
different Funcs doesn't change the behavior of certain AWK scripts). See
more docs under the "Funcs" field here:
https://godoc.org/github.com/benhoyt/goawk/interp#Config

It's kind of a solution in search of a problem right now, but you could use
this to call something simple like strings.Repeat, or something complex
like doing an HTTP request. It was also good to learn more about how to use
the "reflect" package.

Again, feedback welcome.

-Ben

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [ANN] Koazee a library inspired by functional programming and lazy evaluation that takes the hassle out of working with arrays

[ivan . corrales]

Last weeks I've been working on improving performance in Koazee. I put in 
practice all your advices and even though I don't have a second release 
ready, I wrote an article to share my experience trying to improve 
performance

https://www.linkedin.com/pulse/go-performance-tips-iv%C3%A1n-corrales-solera/

I hope this can be useful for someone!

Cheers


El domingo, 11 de noviembre de 2018, 20:27:16 (UTC+1), Iván Corrales Solera 
escribió:
>
> Hey guys, last weeks I've been working on Koazee and I just released a 
> very first version Titi, v0.0.1 . Koazee is a golang library inspired in 
> Lazy evaluation and functional programming that provides us a rich set of 
> operations that can be done over arrays. If you like the clean code and the 
> functional programming I am sure you enjoy it!
>
> Documentation is hosted http://wesovilabs.com/koazee/
>
> And the full code can be found on Github, 
> https://github.com/wesovilabs/koazee
> Any feedback or recommendation will be appreciated! Cheers
>

-- 


"Este mensaje está
dirigido de manera exclusiva a su destinatario y puede 
contener información
privada y confidencial. No lo reenvíe, copie o 
distribuya a terceros que no
deban conocer su contenido. En caso de haberlo 
recibido por error,  rogamos
lo notifique al remitente y proceda a su 
borrado, así como al de cualquier
documento que pudiera adjuntarse.



 Por 
favor tenga en cuenta que
los correos enviados vía Internet no permiten 
garantizar la confidencialidad de
los mensajes ni su transmisión de forma 
íntegra.



 Las opiniones expresadas en el
presente correo pertenecen 
únicamente al remitente y no representan
necesariamente la opinión del 
Grupo BBVA."



 "This
message is intended exclusively for the adressee and 
may contain privileged and
confidential information. Please, do not 
disseminate, copy or distribute it to
third parties who should not receive 
it. In case you have received it by
mistake, please inform the sender and 
delete the message and attachments from
your system.



 Please
keep in 
mind that e-mails sent by Internet do not allow to guarantee neither
the 
confidentiality or the integrity of the messages sent."

-- 
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] The most performant deque of all time?

[Christian Petrin]

FYI, we just released deque [v1.0.2](
https://github.com/ef-ds/deque/blob/master/CHANGELOG.md). Due to the
amazing contributions of Roger Peppe , deque
is not only faster now, but also more efficient! Roger is such an
incredible coder!

Also want to say many thanks for the support. I'm blown away by the amount
of views and clones already! :-)

On Tue, Nov 27, 2018 at 8:42 PM Robert Engels  wrote:

> The fmt_test.go is a perfect example. It only tests the public API so the
> tests are extensive.
>
> There is a huge difference between logic attempting to verify the internal
> logic and state, versus tests that exercise the public api extensively.
>
> I think I’ve talked the point to death... to each his own. Happy coding!
>
> > On Nov 27, 2018, at 9:58 PM, Dan Kortschak <
> dan.kortsc...@adelaide.edu.au> wrote:
> >
> > Sometimes the code used in production is more concise or clever in
> > order to be more performant. The testing code then is more verbose in
> > order to do the work in a less efficient but clearer way. This may
> > result in the test code being longer than the tested code. In addition
> > to this there may be many lines describing test cases in tables; take
> > for example fmt where the fmt_test.go file is 1522 sloc while the
> > format.go and print.go files that it tests are together 1312 sloc,
> > similarly in json where decode_test.go is 1920 sloc and decode.go is
> > 971.
> >
> > Dan
> >
> >> On Tue, 2018-11-27 at 21:40 -0600, robert engels wrote:
> >> If the tests are internal, you technically needs tests for the tests
> >> - based on LOC there is more logic in the tests to “be correct” than
> >> actual lines of code.
> >>
> >> That is a snowballing problem if you ask me… If the code needs 3x LOC
> >> for “internal tests”, its a sign that the actual code is too complex
> >> / poorly designed / structured.
> >>
> >> Public API tests are a completely different thing, as their logic is
> >> documented by the public API.
> >>
> >> Again, JMO.
> >>
> >>>
> >>> On Nov 27, 2018, at 7:55 PM, Freddy Martinez  >>> m> wrote:
> >>>
> >>> Sorry Chris, I haven’t seen the code + tests, I don’t think that
> >>> having x lines of code and 2x lines for test code is a problem, in
> >>> fact, if you use TDD this is very common because you’ll have a
> >>> looot of line code in your tests because this is how TDD works…
> >>>
> >>> Why is this an issue ?
> >>>
> >>> Again, I haven’t seen the code, but IMHO, I don’t think that there
> >>> is a limit in the number line of code in your tests.
> >>>
> >>> Regards
> >>>
> >>>
> >>> =
> >>> Freddy Martínez García
> >>> Software Engineer
> >>> B.S. Computer Science
> >>> LinkedIn: https://ar.linkedin.com/in/freddy-martinez-garcia-4715725
> >>> 9 
> >>>
> >>> “If you give someone a program, you will frustrate them for a day;
> >>> if you teach them how to program, yo will frustrate them for a
> >>> lifetime.”
> >>>
> >>> David Leinweber
> >>>
> >>> On 27 November 2018 at 22:20:25, Christian Petrin (christianpetrin@
> >>> gmail.com ) wrote:
> >>>
> 
>  FYI, I have released deque version 1.0.1   s/deque/blob/master/CHANGELOG.md>. Turns out there was a bug
>  related to spared links. I really appreciate the help, Roger
>  (@rogpeppe), for pointing out and helping fix the bug.
> 
>  On Mon, Nov 26, 2018 at 8:07 PM robert engels   com > wrote:
>  No problem, but just one last word on this…
> 
>  You have 748 lines of internal unit tests and only 295 lines of
>  actual code.. This IMO does not lend itself to maintainable &
>  flexible code. If your 295 lines needs 748 to verify its
>  correctness something is wrong. You have an additional 400 lines
>  of integration tests - if those are full coverage they should be
>  more than enough IMO, but again, just something to think about
>  and to each his own.
> 
> 
> 
> >
> > On Nov 26, 2018, at 9:56 PM, Christian Petrin  > gmail.com > wrote:
> >
> > Moved the non-unit tests to the "deque_test" package. The tests
> > , package-wise, look as they
> > should now. Thanks Robert for the suggestion. :-)
> >
> > On Mon, Nov 26, 2018 at 2:01 PM robert engels  > m.com > wrote:
> > It’s funny though, if you look at the container/ring tests,
> > they test the internal structure, but there are no tests of the
> > behavior, so if the data structure design is not correct, the
> > tests will pass but the operations may not work as expected
> > (especially after a refactor). A case of I know what should
> > happen…
> >
> > And then some public methods like Do()/Move() are not