Re: [go-nuts] Preemptive interfaces in Go

[Tim Peoples]

Responses inline...

On Wednesday, August 10, 2022 at 1:17:21 AM UTC-7 Henry wrote:

> Someone mentioned that data is data and there is no need to hide 
> implementation details. If we are to use that reasoning, there is no need 
> for Go to allow un-exported fields/types/functions. Why do we need them at 
> all? The reason for hiding implementation details is to narrow down the 
> access points to the code. By keeping the access points narrow, it reduces 
> user's cognitive burden and leaves room for future 
> refactoring/changes/extension to the code. It is called abstraction. 
>

I can't really speak to the motivation for the above "data is data" 
statement but my personal interpretation of it is simply that Go provides 
several facilities for *hiding implementation details* without using an 
interface to define your API contract.  If that's what they meant then I 
agree with it; if not, then I doubt I do.  However, I'm still quite lost on 
how exposing my API through an interface enhances my ability to hide 
implementation details beyond what I can do otherwise -- other than, as you 
pointed out earlier, syntactically hiding a pointer value. Other than that, 
it's been my experience that using an interface to wrap a single 
implementation adds little more than an annoying level of indirection.  Of 
course, YMMV.
 

>  Someone also mentioned that you cannot add methods to an interface 
> without breaking compatibility. The only case that this is true is when you 
> have no control over the implementation. If you have control over the 
> implementation, I don't see why you can't add methods to an interface and 
> change its implementation in the same way you would to a struct if you are 
> to return a struct. If you have no access to the struct, you can't add 
> methods to the structs either. It isn't fair to consider this argument as 
> the "return struct" superiority over "return interface".
>

I think you nailed it when you said, "*The only case that this is true is 
when you have no control over the implementation.*" -- and therein lies the 
beauty and power of Go's interfaces over those *explicit interface* 
languages. Since Go's interfaces are *implicit,* they can (and quite often 
should) be defined outside the control of the implementer.  A really good 
example of this is the Marshaler interface from "encoding/json", which is 
defined as: 

type Marshaler interface {
MarshalJSON() ([]byte, error)
}

Any type (anywhere) can implement this interface with package "json" being 
none the wiser.  However, when the logic in json's  Marshal(...) function 
runs into one of these types, it will call its MarshalJSON method as 
intended so the type can customize its JSON representation. Of course, if 
someone were to add a method to the above interface, I cannot imagine the 
number of things that would break.
 

> Readability is subjective. Haskell code is often incredibly terse and 
> elegant. Some people even swear by its readability and comprehension. While 
> I agree that Haskell is elegant, I don't find it to be easy to read. There 
> have been many metrics to measure code readability/comprehension/complexity 
> over the years, and none is quite reliable. I even wrote a linter that was 
> used in my company back then, and the tool became the company's standard 
> that the code must pass before it can be merged to the main branch. 
> Thinking back, what was readable back then is no longer the most readable 
> today. Readability varies from person to person, and it changes over time.
>

The word "readability" was introduced with a very specific context and 
definition. Please see my previous post for a description. 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ffdfe4d5-cccd-4c93-9b5b-7e84361e7524n%40googlegroups.com.

Re: [go-nuts] Preemptive interfaces in Go

[Tim Peoples]

I'm Sorry -- when I said "readability reviewer" I was referring to a very 
google-specific term about how they ensure the author of a change 
understands the language they're writing. Granted, it's been a while since 
I worked there but, at that time, each change request (aka MR, PR, etc...) 
required approval from (1) a code owner and (2) someone with *readability* for 
the language in question -- and, if the author covered both of those, an 
"LGTM" from someone else was still required (i.e. *Minimum Two Brains*). 
Regardless, no code change could be submitted without someone with 
*readability* being involved (either the author or a reviewer).

Each language had their own procedures about how *readability* would be 
granted. For Go, each and every CR from a non-readability SWE would get 
assigned to a random *readability reviewer*  to ensure the code meets 
certain standards and is *idiomatically Go.*  It took me ~15 months and 
just under 60 CRs to get Go *readability* (compared to 4 months and 3 CRs 
for Python).

On Tuesday, August 9, 2022 at 1:08:42 PM UTC-7 bse...@computer.org wrote:

> On Tue, Aug 9, 2022 at 1:52 PM Tim Peoples  wrote:
>
>> Yeah, I'm with Burak on this one. The interface usage you're describing 
>> Henry is exactly the kind of thing I'm talking about.  While on the surface 
>> it may seem advantageous -- in fact, I also tried writing Go that way when 
>> I first started -- my *readability* reviewers at Google did well to 
>> enlighten me about the many problems this can cause with Go -- some of 
>> which rog was kind enough to enumerate.
>
>
> I think "readability" is not the right metric to use here. "Code 
> comprehension" (comprehensibility?) should be the right metric. Readability 
> does not always imply it can be easily comprehended. Java is readable, but 
> not necessarily comprehensible. I argue that Go code is more comprehensible 
> than code written in most other languages, because you can understand all 
> the implications of the code using mostly "local knowledge", that is, 
> knowledge you can gain by reading pieces of code "close" to the point of 
> interest. Wherever you have interfaces, you need non-local knowledge to 
> understand what's going on.
>
>  
>
>>
>> Also, since originally posting this yesterday, I've come to learn that my 
>> new shop is not only utilizing preemptive interface definitions but also a 
>> complete dependency injection framework and rather strict adherence to 
>> *Clean 
>> Architecture*™ 
>> <https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html>
>>  
>> -- (likely from the scripts in this repo 
>> <https://github.com/thnkrn/go-gin-clean-arch>) which goes a long way 
>> towards explaining why so much of the code looks like Java written in Go 
>> syntax.
>>
>> On Tuesday, August 9, 2022 at 8:33:07 AM UTC-7 bse...@computer.org wrote:
>>
>>> On Mon, Aug 8, 2022 at 11:27 PM Henry  wrote:
>>>
>>>> I am sure that many of us have been on that journey. After using Go for 
>>>> some time, we discover some practices that are not necessarily in 
>>>> agreement 
>>>> with the existing "adages" but effectively solve our problems.  
>>>>
>>>> For me, if the data type is mutable, I prefer returning interfaces. It 
>>>> would be something like this:
>>>> ```
>>>> type Student interface {
>>>>//...
>>>> }
>>>>
>>>> type studentImpl struct {
>>>>//...
>>>> }
>>>>
>>>> func NewStudent(id string) Student {
>>>>return {
>>>>   //...
>>>>}
>>>> }
>>>> ```
>>>> There is a bit of history why I use this approach. For a struct with a 
>>>> mutex, I wanted to ensure that the user did not accidentally copy the 
>>>> struct. Nowadays we have *go vet* to give us a warning, but this was 
>>>> before *go vet* had this functionality. So, I return a pointer to the 
>>>> struct and hide it behind an interface. That way, it hides the 
>>>> implementation details from the user and the user can pass the object 
>>>> around without knowing whether it has a mutex or not.
>>>>
>>>> And then I ended up with some *constructors* returning structs and 
>>>> some returning interfaces. To ensure consistency, my colleagues and I 
>>>> decided to return interfaces for all mutable objects. For immutable 
>>>> objects, we return structs.
>>>>
>>>> The n

Re: [go-nuts] Preemptive interfaces in Go

[Tim Peoples]

Yeah, I'm with Burak on this one. The interface usage you're describing 
Henry is exactly the kind of thing I'm talking about.  While on the surface 
it may seem advantageous -- in fact, I also tried writing Go that way when 
I first started -- my *readability* reviewers at Google did well to 
enlighten me about the many problems this can cause with Go -- some of 
which rog was kind enough to enumerate.

Also, since originally posting this yesterday, I've come to learn that my 
new shop is not only utilizing preemptive interface definitions but also a 
complete dependency injection framework and rather strict adherence to *Clean 
Architecture*™ 
<https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html> 
-- (likely from the scripts in this repo 
<https://github.com/thnkrn/go-gin-clean-arch>) which goes a long way 
towards explaining why so much of the code looks like Java written in Go 
syntax.

On Tuesday, August 9, 2022 at 8:33:07 AM UTC-7 bse...@computer.org wrote:

> On Mon, Aug 8, 2022 at 11:27 PM Henry  wrote:
>
>> I am sure that many of us have been on that journey. After using Go for 
>> some time, we discover some practices that are not necessarily in agreement 
>> with the existing "adages" but effectively solve our problems.  
>>
>> For me, if the data type is mutable, I prefer returning interfaces. It 
>> would be something like this:
>> ```
>> type Student interface {
>>//...
>> }
>>
>> type studentImpl struct {
>>//...
>> }
>>
>> func NewStudent(id string) Student {
>>return {
>>   //...
>>}
>> }
>> ```
>> There is a bit of history why I use this approach. For a struct with a 
>> mutex, I wanted to ensure that the user did not accidentally copy the 
>> struct. Nowadays we have *go vet* to give us a warning, but this was 
>> before *go vet* had this functionality. So, I return a pointer to the 
>> struct and hide it behind an interface. That way, it hides the 
>> implementation details from the user and the user can pass the object 
>> around without knowing whether it has a mutex or not.
>>
>> And then I ended up with some *constructors* returning structs and some 
>> returning interfaces. To ensure consistency, my colleagues and I decided to 
>> return interfaces for all mutable objects. For immutable objects, we return 
>> structs.
>>
>> The nice thing about this approach is that it makes the syntax a lot 
>> cleaner as you have to deal with fewer pointers. 
>> ```
>> //instead of this
>> func Update(student *Student) {
>>   //...
>> }
>> func UpdateMany(students []*Student){
>>   //...
>> }
>>
>> //now you have this
>> func Update(student Student) {
>>   //...
>> }
>> func UpdateMany(students []Student){
>>   //...
>> }
>> ```
>> Some members in the team came from higher level languages and they found 
>> working with pointers a bit awkward, so we made some accommodation for 
>> them. 
>>
>
>> There are times when I need to *upgrade* some of these mutable objects, 
>> and this approach has proven to be quite flexible. It also plays nicely 
>> with code generators.
>>
>> Some people may disagree with this approach, but I have been using it 
>> ever since: return interface for mutable objects, return structs for 
>> immutable objects.
>>
>
> I am one of those who disagrees. I have not seen any benefit from having 
> interfaces for data objects other than making other developers happy. In my 
> opinion, this amounts to emulating another language in Go. There are cases 
> where this might make sense, but as a general principle, I think it should 
> be avoided. Data is data. There are no implementation details to hide.
>
>  
>
>> On Tuesday, August 9, 2022 at 3:09:10 AM UTC+7 t...@timpeoples.com wrote:
>>
>>> I can't speak to the *auto-generated swagger client* case but I believe 
>>> gRPC is still doing things the right way -- in that the framework defines 
>>> an interface I (the framework API consumer) then implements.  IOW: I don't 
>>> see that as a "java style interface" (where the interface defines the API 
>>> contract).
>>>
>>> I suspect you and I are saything the same thing.
>>>
>>> t.
>>>
>>> On Monday, August 8, 2022 at 12:51:29 PM UTC-7 bse...@computer.org 
>>> wrote:
>>>
>>>> On Mon, Aug 8, 2022 at 12:51 PM Tim Peoples  
>>>> wrote:
>>>>
>>>>> I don't necessarily consider the "multiple implementations

Re: [go-nuts] Preemptive interfaces in Go

[Tim Peoples]

I can't speak to the *auto-generated swagger client* case but I believe 
gRPC is still doing things the right way -- in that the framework defines 
an interface I (the framework API consumer) then implements.  IOW: I don't 
see that as a "java style interface" (where the interface defines the API 
contract).

I suspect you and I are saything the same thing.

t.

On Monday, August 8, 2022 at 12:51:29 PM UTC-7 bse...@computer.org wrote:

> On Mon, Aug 8, 2022 at 12:51 PM Tim Peoples  wrote:
>
>> I don't necessarily consider the "multiple implementations" case as being 
>> truly preemptive -- if there really are multiple implementations (e.g. the 
>> "hash" package from the standard library).
>>
>> I'm much more concerned about interfaces that are defined by an API 
>> producer -- for one and only one impl -- and then adding a bunch of extra 
>> (often autogenerated) code to deal with that.
>>
>
> Like a gRPC client/server, or auto-generated swagger client/server?
>
> I've had many instances where such an auto-generated client had to be 
> passed down components that have no knowledge of those services. Writing 
> such components using interfaces declaring only parts of those service 
> implementations have benefits. An example that I can think of is an 
> audit-trail service that deals with recording transaction metadata, looking 
> them up, etc. It makes sense to write components that use only the writer 
> part of that service, instead of requiring the whole thing. It makes 
> writing tests easier. It lets you decouple services better, add 
> adapters/interceptors etc.
>  
>
>>
>> t.
>>
>> On Monday, August 8, 2022 at 11:02:31 AM UTC-7 bse...@computer.org wrote:
>>
>>> On Mon, Aug 8, 2022 at 11:17 AM Tim Peoples  wrote:
>>>
>>>>
>>>> For years I've read the old adage, "Accept interfaces, return structs" 
>>>> and have spent years working to instill this understanding among my 
>>>> colleagues. I gathered a great many skills while learning Go (and 
>>>> acquiring 
>>>> readability)  back in the day -- and one of the strongest of those is the 
>>>> idea that interfaces should be defined by their consumer instead of an API 
>>>> producer -- but I've now been away from Google longer than I was there and 
>>>> I'm beginning to suspect that the general consensus among the *Go 
>>>> Literati* may have shifted around some things -- like preemptive 
>>>> interfaces.
>>>>
>>>> My arguments against preemptive interfaces have recently run into more 
>>>> and more pushback  -- especially among the influx of developers coming 
>>>> from 
>>>> the Java and/or C# world who seem to continually reject any notion that Go 
>>>> should be any different from the way they've always done things.
>>>>
>>>> This has recently come to a head with a brand new job (I'm 3 weeks in) 
>>>> where virtually all of their services are built atop a dependency 
>>>> injection 
>>>> framework having a data model with dozens (if not hundreds) of preemptive 
>>>> interfaces and my initial, cursory review tells me the codebase is at 
>>>> least 
>>>> an order of magnitude more complex that it needs to be.  (Note, I was told 
>>>> that none SWEs at this company (other than myself) knew any Go before they 
>>>> started).
>>>>
>>>> So, my questions to the group are thus, "Should I even care about this 
>>>> at all?  Are preemptive interfaces now considered the norm with Go? Or, 
>>>> should I just shut up and crawl back into my hole?
>>>>
>>>
>>> I believe both approaches have their uses. What you call preemptive 
>>> interfaces can be effectively used to hide implementation details where 
>>> multiple implementations can exist. This approach can coexist very well 
>>> with interfaces defined by the consumer. For example we have services that 
>>> are written to implement an interface, so it becomes a logical deployment 
>>> unit. Then we have consumers of that service that define parts of the 
>>> interface service implements, so the consumer is not dependent on the 
>>> complete service, and we can add any interceptors/filters.
>>>
>>> However, I agree with your assessment that especially newcomers tend to 
>>> choose the traditional "interface is a contract" approach. In addition to 
>>> the effect of other languages, people seem to like "clean arc

Re: [go-nuts] Preemptive interfaces in Go

[Tim Peoples]

I don't necessarily consider the "multiple implementations" case as being 
truly preemptive -- if there really are multiple implementations (e.g. the 
"hash" package from the standard library).

I'm much more concerned about interfaces that are defined by an API 
producer -- for one and only one impl -- and then adding a bunch of extra 
(often autogenerated) code to deal with that.

t.

On Monday, August 8, 2022 at 11:02:31 AM UTC-7 bse...@computer.org wrote:

> On Mon, Aug 8, 2022 at 11:17 AM Tim Peoples  wrote:
>
>>
>> For years I've read the old adage, "Accept interfaces, return structs" 
>> and have spent years working to instill this understanding among my 
>> colleagues. I gathered a great many skills while learning Go (and acquiring 
>> readability)  back in the day -- and one of the strongest of those is the 
>> idea that interfaces should be defined by their consumer instead of an API 
>> producer -- but I've now been away from Google longer than I was there and 
>> I'm beginning to suspect that the general consensus among the *Go 
>> Literati* may have shifted around some things -- like preemptive 
>> interfaces.
>>
>> My arguments against preemptive interfaces have recently run into more 
>> and more pushback  -- especially among the influx of developers coming from 
>> the Java and/or C# world who seem to continually reject any notion that Go 
>> should be any different from the way they've always done things.
>>
>> This has recently come to a head with a brand new job (I'm 3 weeks in) 
>> where virtually all of their services are built atop a dependency injection 
>> framework having a data model with dozens (if not hundreds) of preemptive 
>> interfaces and my initial, cursory review tells me the codebase is at least 
>> an order of magnitude more complex that it needs to be.  (Note, I was told 
>> that none SWEs at this company (other than myself) knew any Go before they 
>> started).
>>
>> So, my questions to the group are thus, "Should I even care about this at 
>> all?  Are preemptive interfaces now considered the norm with Go? Or, should 
>> I just shut up and crawl back into my hole?
>>
>
> I believe both approaches have their uses. What you call preemptive 
> interfaces can be effectively used to hide implementation details where 
> multiple implementations can exist. This approach can coexist very well 
> with interfaces defined by the consumer. For example we have services that 
> are written to implement an interface, so it becomes a logical deployment 
> unit. Then we have consumers of that service that define parts of the 
> interface service implements, so the consumer is not dependent on the 
> complete service, and we can add any interceptors/filters.
>
> However, I agree with your assessment that especially newcomers tend to 
> choose the traditional "interface is a contract" approach. In addition to 
> the effect of other languages, people seem to like "clean architecture". 
> Nevertheless, even with people dedicated to clean architecture, the idea of 
> "interface parts" seems to resonate, especially when you show that you can 
> define an interface on the consumer side that combines parts of multiple 
> "contracts".
>  
>
>>
>> TIA,
>> Tim.
>>
>> -- 
>> 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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/f4777928-875d-4c0a-a4a7-9fb57bf9d51fn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/f4777928-875d-4c0a-a4a7-9fb57bf9d51fn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/34469b98-c37e-4a1d-af13-729b639a71ben%40googlegroups.com.

[go-nuts] Preemptive interfaces in Go

[Tim Peoples]

For years I've read the old adage, "Accept interfaces, return structs" and 
have spent years working to instill this understanding among my colleagues. 
I gathered a great many skills while learning Go (and acquiring 
readability)  back in the day -- and one of the strongest of those is the 
idea that interfaces should be defined by their consumer instead of an API 
producer -- but I've now been away from Google longer than I was there and 
I'm beginning to suspect that the general consensus among the *Go Literati* 
may have shifted around some things -- like preemptive interfaces.

My arguments against preemptive interfaces have recently run into more and 
more pushback  -- especially among the influx of developers coming from the 
Java and/or C# world who seem to continually reject any notion that Go 
should be any different from the way they've always done things.

This has recently come to a head with a brand new job (I'm 3 weeks in) 
where virtually all of their services are built atop a dependency injection 
framework having a data model with dozens (if not hundreds) of preemptive 
interfaces and my initial, cursory review tells me the codebase is at least 
an order of magnitude more complex that it needs to be.  (Note, I was told 
that none SWEs at this company (other than myself) knew any Go before they 
started).

So, my questions to the group are thus, "Should I even care about this at 
all?  Are preemptive interfaces now considered the norm with Go? Or, should 
I just shut up and crawl back into my hole?

TIA,
Tim.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f4777928-875d-4c0a-a4a7-9fb57bf9d51fn%40googlegroups.com.

Re: [go-nuts] Re: Ternary ... again

[Tim Peoples]

Regarding your issues with the following...
 

> I've lost count of the times I've had to change:
>
> return FooBar{
> Field: blah,
> }
>
> To:
>
> var foo FooBar
> if someCond {
> foo.Field = blah
> } else {
> foo.Field = bar
> }
> return foo
>

 ...I hardly consider that to be idiomatic Go.  A more go-like approach 
would be to follow the guideline to "return early" and write it more like 
this:

 if someCond {
  return FooBar{Field: blah}
}

return FooBar{Field: bar}


...which (IMHO) is markedly more readable than a ternary expression.

-- 
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: My trouble about GO interface

[Tim Peoples]

I think the confusion comes from how you're exposing each interface -- or 
rather, how you seem to imply their use.

In your example, you provide packages pet and filepath each of which define 
a Walk interface *plus* one or more structs that implement that interface. 
But, neither package consumes the Walk interface they define.  This is what 
Jack 
Lindamood refers to as a *preemptive interface* and it's contrary to 
idiomatic Go.

While your usage pattern is quite common in Java (or similar) -- where a 
package exposes a public interface as a "contract" for its behavior and is 
then free to change its implementing class behind the scenes (as long as it 
continues to implement the published interface) -- that is not how Go 
interfaces are meant to be used.  Instead, a Go interface should be defined 
in the package where it will be received in an argument list and the 
"contract" is defined by the documentation for the interface (e.g. "If you 
hand me a Fooer, I'm going call Foo() under these conditions and expect it 
to do A, B and C.").  This way, anyone can implement that interface and 
pass it as an argument to your function (or method).

This is why most Go interfaces define very few methods (often only one).

If you stick to only defining an interface when and where you actually need 
one -- and live by the adage "Accept interfaces, return structs" -- I think 
this will make a lot more sense.

See the following for more info:

   - Preemptive Interface Anti-Pattern in Go 
   

   - What “accept interfaces, return structs” means in Go 
   

   

t.


On Wednesday, August 8, 2018 at 10:21:55 PM UTC-7, Ally Dale wrote:
>
> Hi everyone,
> I have some confusion about GO's interface:
> 1. Some different interface but with the same signature
> I have put an example here: 
> https://github.com/vipally/glab/blob/master/lab12/walk_test.go
> The confusion is, there are two different interface filepath.Walker and 
> pet.Walker.
> filepath.Walker is designed for "visit all files of a filepath"
> pet.Walker is designed for "walk action of animals"
> But unfortunately, both signature is the same:
> type Walker interface {
>  Walk()
> }
>
> But in go syntax, the follow usage is legal:
> var petWalker pet.Walker
> petWalker = {}
> petWalker.Walk()
>
> But it's obviously that this usage is out of plan.
> 2. Cannot find all types that has implements an interface
> Go tools is hard to find type pet.Dog and pet.Cat through pet.Walker,
> Because there is no declarations of the relations between them.
>
> Maybe this outter-declaration can solve this problem?
> //declare which types has implements this interface
> implements pet.Walker{
>  *pet.Dog
>  *pet.Cat
> }
> //declare this type has implement any interfaces
> implements *filepath.FilePath{
>   filepath.Walker
>   filepath.Reader
> }
>
>
>
>
> Ally.
>

-- 
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: github repo names with "go-" prefix?

[Tim Peoples]

...and yet, a vast majority of the instances where I see a go package 
hosted as "github.com/user/go-foobar", they are not using gopkg.in.

I'm w/ Dave on this one; except in very rare instances, this shouldn't be 
done (and even then, you should try find a way to avoid it).

Also, in many ways, this is a side effect of github's insistence that all 
their users live within a flat namespace.  (n.b. I once had Chris Wanstrath 
ask me which one feature I thought was missing from Github. I told him 
"global cross reference links". I should have said, "How about a 
hierarchical namespace?") 

t.

On Sunday, December 24, 2017 at 4:40:43 AM UTC-8, Tamás Gulácsi wrote:
>
> gopkg.in forces me to have github.com/go-goracle/goracle to produce 
> gopkg.in/goracle.v2 as the import path. Seemed to be a little price for a 
> nice import path.

-- 
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] github repo names with "go-" prefix?

[Tim Peoples]

On Saturday, December 23, 2017 at 11:36:45 AM UTC-8, Jakob Borg wrote:
>
> On 23 Dec 2017, at 19:18, Tim Peoples <t...@timpeoples.com > 
> wrote: 
> > 
> > I've noticed a somewhat common practice of people naming their github 
> repositories with a "go-" prefix (and then, of course, subsequently 
> dropping the prefix in the actual package name) -- yet a similar naming 
> scheme doesn't seem to be commonplace among many other languages. 
>
> I think this is acceptable when you’re providing a library foo implemented 
> in several languages and naturally get go-foo, python-foo, ruby-foo etc 
> repositories. It’s still annoying but a natural effect of using the GitHub 
> etc namespace for package naming and not having a Go specific package 
> namespace. 
>
> In all other cases it’s discouraged. 
>
> //jb 
>

Sadly, that is rarely the case.

In fact, I often find authors with dozens of repos covering a number of 
languages -- yet, only their "go" repos are named as such (repos with no 
corresponding implementation in another language, mind you).

Oh well... :/

t.

-- 
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: github repo names with "go-" prefix?

[Tim Peoples]

On Saturday, December 23, 2017 at 11:06:35 AM UTC-8, Dave Cheney wrote:
>
> On Sunday, 24 December 2017 05:18:14 UTC+11, Tim Peoples  wrote: 
> > I've noticed a somewhat common practice of people naming their github 
> repositories with a "go-" prefix (and then, of course, subsequently 
> dropping the prefix in the actual package name) -- yet a similar naming 
> scheme doesn't seem to be commonplace among many other languages. 
> > 
>
> I believe the zeitgeist originated with JavaScript. 
>
> > 
> > Is this recommended somewhere?  If so, where? 
> > 
>
> It is not recommended for your package’s  repository or directory name to 
> differ from its  package declaration. 
>
> > 
> > Conversely, is it explicitly discouraged? 
>
> Yes, for the reasons above, it’s confusing, also it’s redudant for the 
> same reasons go programmers do not start interface declarations with a 
> capital I. 
>
>
Thanks Dave, that's exactly what I'd assumed (but didn't want to overly 
expose my original bias).

I only asked because every time I see this, it tends to make me wince (and 
I often end up forking the repo just so I can rename it).

I suppose the real question is, "How do we get people to stop?" :D

-- 
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: github repo names with "go-" prefix?

[Tim Peoples]

[*yes, I'm responding to myself (I tend to do that sometimes)*]

Hmm I suspect part of it may be coming from this PackagePublishing wiki 
page <https://github.com/golang/go/wiki/PackagePublishing#subdirectories>, 
where 
it's mentioned almost as a foregone conclusion yet may often be interpreted 
as a recommendation.

However, I'll assume the genesis is elsewhere.


On Saturday, December 23, 2017 at 10:18:14 AM UTC-8, Tim Peoples wrote:
>
>
> I've noticed a somewhat common practice of people naming their github 
> repositories with a "go-" prefix (and then, of course, subsequently 
> dropping the prefix in the actual package name) -- yet a similar naming 
> scheme doesn't seem to be commonplace among many other languages.
>
> Is this recommended somewhere?  If so, where?
>
> Conversely, is it explicitly discouraged?
>
>
>

-- 
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] github repo names with "go-" prefix?

[Tim Peoples]

I've noticed a somewhat common practice of people naming their github 
repositories with a "go-" prefix (and then, of course, subsequently 
dropping the prefix in the actual package name) -- yet a similar naming 
scheme doesn't seem to be commonplace among many other languages.

Is this recommended somewhere?  If so, where?

Conversely, is it explicitly discouraged?


-- 
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: Dangers of package renaming

[Tim Peoples]

You may want to consider using a type alias -- similar to how 
golang.org/x/net/context  
is being transitioned to the standard library's context 
 package.

Also, Russ Cox wrote an excellent article about codebase refactoring 
; I highly recommend it.


On Saturday, December 2, 2017 at 7:33:06 AM UTC-8, Jonathan Hall wrote:
>
> I maintain an open-source Go package with a few dozen followers.  (
> github.com/flimzy/kivik)
>
> I'm planning to transfer/rename the package to a new organization (new 
> package name to be: github.com/go-kivik/kivik).
>
> I understand that GitHub will maintain a redirect from the old location to 
> the new one, so in theory, old imports will continue working.
>
> But my question is: Are there any dangers I need to consider when making 
> this change, and is there anything I can do to help mitigate such dangers?  
> I ask mainly because I've read of some nightmares related to package 
> renaming (example: 
> https://github.com/sirupsen/logrus/issues/570#issuecomment-313933276), 
> and want to do everything possible to prevent such problems for my own 
> package.  (To be clear: I don't think the Sirupsen problem in particular 
> will affect me, since it's not just a capitalization change).
>
> Keep in mind that the package has sub-packages as a dependencies (i.e. 
> github.com/flimzy/kivik dependson github.com/flimzy/kivik/errors), in 
> case this complicates things.
>
> Thank you,
>
> Jonathan
>
>

-- 
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: Bug report github.com/golang/glog

[Tim Peoples]

You're absolutely right -- and, if you'll notice, there's a TODO on the 
traceLocation.String() method 
 to "clean this 
up".

Granted, all it needs is a:

if !t.isSet() {
  return ""
}



On Friday, November 17, 2017 at 5:27:49 PM UTC-8, Brian Kennedy wrote:
>
> For the flag "log_backtrace_at" the flag expects "" for an empty value 
> when calling Set(), but .String() will return ":0" when the value is empty. 
> This results in a different "emtpy" value being generated by String() than 
> is accepted by Set().
>
> The following code will reproduce the issue.
>
> *Output from process:*
> Value: ":0"
> Setting flag returned error: syntax error: expect file.go:234
>
> *Code Snippet:*
>
> package main
>
> import (
>   "flag"
>   "fmt"
>
>   "github.com/golang/glog"
> )
>
> func main() {
>   flag.Parse()
>
>   lba := flag.Lookup("log_backtrace_at")
>   if lba == nil {
> glog.Fatalf("Needs to depend on glog")
>   }
>   fmt.Printf("Value: \"%s\"\n", lba.Value.String())
>   err := lba.Value.Set(lba.Value.String())
>   if err != nil {
> fmt.Printf("Setting flag returned error: %s\n", err)
>   }
> }
>
>

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