Re: [go-nuts] Package Stutter

[Dan Kortschak]

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

List list = singletonList(someobject)

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



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

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

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

[Iván Corrales Solera]

Hey Marko,

I already have benchmark for Koazee... Many changes have been done in code 
in order to improve the performance (At the  moment being focused on 
improve performance for primitive types). Make comparison  with other 
frameworks is complicated to me but I invite the owners of other similar 
tools to run the re-use my tests!

Benchmark report can be found here: 
https://github.com/wesovilabs/koazee/wiki/Benchmark-Report








On Monday, November 12, 2018 at 8:59:20 AM UTC+1, Marko Ristin wrote:
>
> Hi Ivan,
> Any performance comparisons with other approaches would be greatly 
> appreciated and I assume they would also help the adoption a lot.
>
> Cheers Marko 
>
> Le lun. 12 nov. 2018 à 08:20, Iván Corrales Solera <
> ivan.corra...@gmail.com > a écrit :
>
>> Hey Marko,
>>
>> Thanks you so much for your reply!,
>>
>>
>> To be honest I didn't know about this libraries, but after having a quick 
>> look at them I see that
>>
>> The set of provided operations in https://github.com/clementauger/st 
>> 
>>  is 
>> more reduced (but I assume it will be increased), and in the case of  
>> https://github.com/ahmetb/go-linq 
>> 
>>  I 
>> should take time to having a look and find the difference,  because like 
>> Koazee both are based on Lazy evaluation, so the provided functionality is 
>> similar. 
>>
>> As a strong point of koazee I would say the documentation, 
>> http://wesovilabs.com/koazee/ and that Koazee is only 1 week from I 
>> started to code it, then there are  and much more possibilities are 
>> supported, 
>>
>> In fact,An hour ago,  I just created some issues which will provide extra 
>> functionality not provided by  https://github.com/ahmetb/go-linq 
>> 
>>   
>> for example this one
>>
>> https://github.com/wesovilabs/koazee/issues/2
>>
>> In fact any new issues or suggestion will be great!
>>
>> Thank you so much again
>>
>>
>> On Monday, November 12, 2018 at 8:01:28 AM UTC+1, Marko Ristin wrote:
>>>
>>> Hi!
>>> Could you give a comparison to other similar libraries such as 
>>> https://github.com/clementauger/st
>>> https://github.com/ahmetb/go-linq
>>> ?
>>>
>>> Cheers Marko
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

Re: [go-nuts] Package Stutter

[Robert Engels]

If can go as far as

List list = sort(reverse(somelist))

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

> On Dec 2, 2018, at 2:55 AM, Dan Kortschak  wrote:
> 
> That's pretty different to a dot import in Go. If the imports below
> gave you 
> 
> List list = singletonList(someobject)
> 
> Then they would be comparable - the static imports are more comparable
> to Go's dot imports, but then in your next post you say that they're
> mainly used for constants, "although for some types of routines it is
> used to make the code read like a DSL."
> 
> 
> 
>> On Sun, 2018-12-02 at 00:04 -0600, robert engels wrote:
>> When you use
>> 
>> import java.util.Collections;
>> import java.util.List;
>> 
>> You are actually doing a dot import, so you can in the code just
>> refer to it as so
>> 
>> List list = Collections.singletonList(someobject)
>> 
>> otherwise you need to write the code as:
>> 
>> java.util.List list =
>> java.util.Collections.singletonList(someobject);
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Package Stutter

['Niko Schwarz' via golang-nuts]

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

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

Niko

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

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

[go-nuts] [ANN] aah Go web framework v0.12.0 Released!

[Jeevanandam M.]

Website: https://aahframework.org
Documentation: https://docs.aahframework.org

Release notes: https://docs.aahframework.org/v0.12/release-notes.html

Your feedback is very valuable. Thanks.

Cheers,
Jeeva

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

Re: [go-nuts] Package Stutter

[roger peppe]

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

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

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

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

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

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

[go-nuts] [Go2] move everything to gopath so goroot isn't required anymore

[Gert]

Can we move stdlib (goroot) to gopath in Go2? On install you can do go get 
-u stdlib to download the stdlib into gopath. Basically getting rid of 
goroot.

-- 
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] [Go2] move everything to gopath so goroot isn't required anymore

[Sam Whited]

There has been some discussion of making packages in the standard library into 
modules (once that's the default versioning system) which could be versioned 
separately from Go so that fixes could be released without having to wait on 
the full Go release cycle. I can't find a link at the moment, but the Go team 
has mentioned the possibility of doing this.

—Sam

On Sun, Dec 2, 2018, at 21:04, Gert wrote:
> Can we move stdlib (goroot) to gopath in Go2? On install you can do go get 
> -u stdlib to download the stdlib into gopath. Basically getting rid of 
> goroot.

-- 
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] [Go2] move everything to gopath so goroot isn't required anymore

[Gert]

Ok thx I will also look on the github repo if I can find it, if not I 
create a new one

On Monday, December 3, 2018 at 4:22:48 AM UTC+1, Sam Whited wrote:
>
> There has been some discussion of making packages in the standard library 
> into modules (once that's the default versioning system) which could be 
> versioned separately from Go so that fixes could be released without having 
> to wait on the full Go release cycle. I can't find a link at the moment, 
> but the Go team has mentioned the possibility of doing this. 
>
> —Sam 
>
> On Sun, Dec 2, 2018, at 21:04, Gert wrote: 
> > Can we move stdlib (goroot) to gopath in Go2? On install you can do go 
> get 
> > -u stdlib to download the stdlib into gopath. Basically getting rid of 
> > goroot. 
>

-- 
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] [Go2] move everything to gopath so goroot isn't required anymore

[Gert]

https://github.com/golang/go/issues/29070

On Monday, December 3, 2018 at 5:01:59 AM UTC+1, Gert wrote:
>
> Ok thx I will also look on the github repo if I can find it, if not I 
> create a new one
>
> On Monday, December 3, 2018 at 4:22:48 AM UTC+1, Sam Whited wrote:
>>
>> There has been some discussion of making packages in the standard library 
>> into modules (once that's the default versioning system) which could be 
>> versioned separately from Go so that fixes could be released without having 
>> to wait on the full Go release cycle. I can't find a link at the moment, 
>> but the Go team has mentioned the possibility of doing this. 
>>
>> —Sam 
>>
>> On Sun, Dec 2, 2018, at 21:04, Gert wrote: 
>> > Can we move stdlib (goroot) to gopath in Go2? On install you can do go 
>> get 
>> > -u stdlib to download the stdlib into gopath. Basically getting rid of 
>> > goroot. 
>>
>

-- 
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] [ANN] GQ - a new library to build GraphQL servers in Go

[staticsnow]

GQ is a new library to build GraphQL servers in Go.


When HouseCanary set out to build a GraphQL server to act as an API gateway 
to a number of existing services, we found that none of the existing 
libraries had quite the functionality we wanted. The biggest challenge was 
in scheduling batched calls to other services. All existing projects seemed 
to support only time based batching. We wanted to we able to 
deterministically schedule calls at convenient points in the query 
execution, similar to what one would do in Node by scheduling batch calls 
at the next event loop tick. In addition, each of the existing libraries 
seemed to fall short in some aspect of the developer experience. We 
researched the following libraries before creating this project:


gqlgen

  - Schema first approach. You write a schema, and then bind types to the 
schema in a config file, then use the schema and config file to generate 
code.

  - Weakness - need to keep definitions in schema and structs in sync, 
requires code generation.


gophers

  - Schema first approach. You write a schema, and then provide a root type 
to bind to the schema. Methods are bound to the schema.

  - Weakness - you have to write a method for each field, leading to lots 
of boilerplate for large DTOs.


graphql-go

  - Schema in code. You build up the schema by constructing it in Go 
objects.

  - Weakness - very verbose/boilerplate heavy, not type checked.


thunder

  - Schema built from structs, with separate method registration.

  -Weakness - verbose registration of resolver methods. Limited flexibility 
in schema definition.


After researching each of these options, we set out to build a struct-first 
development experience that needed minimal boiler plate code, leveraged the 
power of GraphQL schema definitions, and allowed for efficient query 
batching. You can see the results of our work at 
https://github.com/housecanary/gq for documentation and examples of how the 
library diverges from existing GraphQL libraries for Go.


At HouseCanary we are using this library as the foundation to a major 
internal service. We expect to continue to improve and maintain this 
library.

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

Re: [go-nuts] Package Stutter

[Ian Lance Taylor]

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

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

Ian

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

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

[Ian Lance Taylor]

On Sat, Dec 1, 2018 at 9:39 AM  wrote:
>
> 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?

One approach is

s := (*[1<<30]byte)(unsafe.Pointer(mf.GetData())[:mf.GetLength():mf.GetLength()]

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]

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

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

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

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

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

Re: [go-nuts] Package Stutter

[robert engels]

Roger,

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

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

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

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

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






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