[go-nuts] Unescape html in template/html
Hi All,
I am building a twitter clone to learn golang and i need to unescape the
hashtag url.
full source in github github.com/ccaglak/twr
thanks all in advance
for i, v := range gPost {
h := GetHashTags(v.Post)
for _, ht := range h {
gPost[i].Post = strings.Replace(gPost[i].Post, ht, ""+ht+"", -1)
}
}
if a == true {
tmpl.ExecuteTemplate(w, "timeline.htm", &App{Post: gPost, FUser:
foll})
} else {
http.Redirect(w, r, "/login", 302)
}
--
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: Go vet context leak error
One possibility:
func (s *SimplePeerConn) Read(b []byte) (n int, err error) {
ctx, maybeCancelFn := func() (context.Context, context.CancelFunc) {
s.deadlineLock.RLock()
defer s.deadlineLock.RUnlock()
if !s.readDeadline.IsZero() {
return context.WithDeadline(context.Background(), s.readDeadline)
}
return context.Background(), nil
}()
if maybeCancelFn != nil {
defer maybeCancelFn()
}
return s.ReadWithContext(ctx, b)
}
But still a bit annoying to have go vet try to capture these use cases.
Maybe the cancel fn leak test should have a better reachability algo or a
reduced set of parameters where it's considered unreachable (i.e. when the
var is used in other ways)?
On Monday, February 6, 2017 at 3:35:05 PM UTC-6, Chad Retz wrote:
>
> I have the following function:
>
> func (s *SimplePeerConn) Read(b []byte) (n int, err error) {
> ctx := context.Background()
> var maybeCancelFn context.CancelFunc
> func() {
> s.deadlineLock.RLock()
> defer s.deadlineLock.RUnlock()
> if !s.readDeadline.IsZero() {
> ctx, maybeCancelFn = context.WithDeadline(ctx, s.readDeadline)
> }
> }()
> if maybeCancelFn != nil {
> defer maybeCancelFn()
> }
> return s.ReadWithContext(ctx, b)
> }
>
> And I'm getting a possible context leak when I assign maybeCancelFn. I
> originally had context.WithCancel and then overwrote the cancelFn in the
> inner func.
> How would I idiomatically rewrite this to not see the vet error?
>
--
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] Go vet context leak error
I have the following function:
func (s *SimplePeerConn) Read(b []byte) (n int, err error) {
ctx := context.Background()
var maybeCancelFn context.CancelFunc
func() {
s.deadlineLock.RLock()
defer s.deadlineLock.RUnlock()
if !s.readDeadline.IsZero() {
ctx, maybeCancelFn = context.WithDeadline(ctx, s.readDeadline)
}
}()
if maybeCancelFn != nil {
defer maybeCancelFn()
}
return s.ReadWithContext(ctx, b)
}
And I'm getting a possible context leak when I assign maybeCancelFn. I
originally had context.WithCancel and then overwrote the cancelFn in the
inner func.
How would I idiomatically rewrite this to not see the vet error?
--
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] Compiling a really really large package
Good deal. Issue opened at https://github.com/golang/go/issues/18602 and I attached code to replicate. On Tuesday, January 10, 2017 at 3:31:11 PM UTC-6, Ian Lance Taylor wrote: > > On Tue, Jan 10, 2017 at 9:47 AM, > > wrote: > > > > Is there any value in me reporting it? If helpful, I may be able to toss > a > > large tarball up on Dropbox or something. It's not really high priority > for > > me either tbh because I know it would be difficult to stream the > compilation > > inside the same package w/ circular refs and therefore may not be fixed > for > > years. Thanks for your help. > > Yes, it's useful to report it at https://golang.org/issue. It's > useful to have real test cases. 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] Compiling a really really large package
Is there any value in me reporting it? If helpful, I may be able to toss a large tarball up on Dropbox or something. It's not really high priority for me either tbh because I know it would be difficult to stream the compilation inside the same package w/ circular refs and therefore may not be fixed for years. Thanks for your help. On Tuesday, January 10, 2017 at 11:35:32 AM UTC-6, Ian Lance Taylor wrote: > > On Tue, Jan 10, 2017 at 9:22 AM, > > wrote: > > > > Just as an update, Go 1.8 doesn't help much, and the compile flags do > reduce > > memory usage which only extends the inevitable time it runs out of > memory. I > > guess I am at a loss here. I suppose this is not considered a bug, > correct? > > Just a practical limitation of the compiler to use more memory > proportional > > to same-package code size? > > Oh, no, it's definitely a bug. It's just very hard to fix and rare in > practice, so it's not high priority. > > 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] Compiling a really really large package
Just as an update, Go 1.8 doesn't help much, and the compile flags do reduce memory usage which only extends the inevitable time it runs out of memory. I guess I am at a loss here. I suppose this is not considered a bug, correct? Just a practical limitation of the compiler to use more memory proportional to same-package code size? On Monday, January 9, 2017 at 12:24:36 PM UTC-6, Ian Lance Taylor wrote: > > On Mon, Jan 9, 2017 at 9:00 AM, > wrote: > > I have a really really large package of code that was generated via a > code > > generator. Granted the main code that references it I expect to remove a > lot > > via DCE or something so the binaries wouldn't be extreme. The code is > > > 140MB in the single package which I know sounds extreme. Let's ignore > > practical solutions like reducing code size. I have attempted to compile > on > > my Windows machine and the compile process just runs out of memory and > is > > unable to allocate anymore. I tried on a 4G VM w/ 8G swap and after > almost > > two hours it just gets killed (e.g. "go build example.com/pkg: > > /usr/local/go/pkg/tool/linux_amd64/compile: signal: killed"). > > > > This is with Go 1.7, I have not tested with Go 1.8 but will shortly. I > was > > hoping the compiler would be able to scale, even on a single package, > where > > it could stream the compilation. Are there any flags I should pass to go > > build to make it use less RAM? Is there an effective upper limit on > package > > size or any plans to make the compiler not use linearly-more memory > based on > > code size? I can give instructions on how to build this extreme amount > of > > code too if anyone else wants to try. > > There has been some work on improving the compilation of very large > packages in Go 1.8. I expect that more work needs to be done. > > You can try compiling with -gcflags=-N to disable the optimizers and > -gcflags=-l to disable the inliner. That may reduce the memory > requirements, though of course the generated code will be worse. That > may not matter for your case. > > 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] Compiling a really really large package
In my case, many of the functions are very small (many only a single line
that I'm hoping will be inlined). This is a transpiler from another
language (Java) akin to Grumpy (Python) and many of the functions are
single-line dispatch methods to support OOP. The transpiler is at
https://github.com/cretz/goahead if you're curious ("sbt buildRt" w/ the
right env vars builds the 150MB stdlib). It has no documentation yet and is
early in its life.
On Monday, January 9, 2017 at 1:02:14 PM UTC-6, Than McIntosh wrote:
>
> One thing to keep in mind: generated-code compilation time issues can
> sometimes be due to a large function (or functions) as opposed just the
> total volume of code in the package.
>
> For example, https://github.com/golang/go/issues/16407 demonstrates a
> compile-time problem that sounds a bit like what you are seeing. The
> problem can be avoided by tweaking the generator so that it creates a
> collection of smaller functions as opposed to a single giant function. See
> https://github.com/zhenjl/xparse/pull/2.
>
> Depending on how your generator works (and whether you have control over
> it) maybe this is something you can consider.
>
>
> On Mon, Jan 9, 2017 at 1:28 PM, > wrote:
>
>> It does matter for my use case, but not for these first steps. Thanks. I
>> think still, practically, I need to reduce the code size unfortunately.
>>
>> On Monday, January 9, 2017 at 12:24:36 PM UTC-6, Ian Lance Taylor wrote:
>>
>>> On Mon, Jan 9, 2017 at 9:00 AM, wrote:
>>> > I have a really really large package of code that was generated via a
>>> code
>>> > generator. Granted the main code that references it I expect to remove
>>> a lot
>>> > via DCE or something so the binaries wouldn't be extreme. The code is
>>> >
>>> > 140MB in the single package which I know sounds extreme. Let's ignore
>>> > practical solutions like reducing code size. I have attempted to
>>> compile on
>>> > my Windows machine and the compile process just runs out of memory and
>>> is
>>> > unable to allocate anymore. I tried on a 4G VM w/ 8G swap and after
>>> almost
>>> > two hours it just gets killed (e.g. "go build example.com/pkg:
>>> > /usr/local/go/pkg/tool/linux_amd64/compile: signal: killed").
>>> >
>>> > This is with Go 1.7, I have not tested with Go 1.8 but will shortly. I
>>> was
>>> > hoping the compiler would be able to scale, even on a single package,
>>> where
>>> > it could stream the compilation. Are there any flags I should pass to
>>> go
>>> > build to make it use less RAM? Is there an effective upper limit on
>>> package
>>> > size or any plans to make the compiler not use linearly-more memory
>>> based on
>>> > code size? I can give instructions on how to build this extreme amount
>>> of
>>> > code too if anyone else wants to try.
>>>
>>> There has been some work on improving the compilation of very large
>>> packages in Go 1.8. I expect that more work needs to be done.
>>>
>>> You can try compiling with -gcflags=-N to disable the optimizers and
>>> -gcflags=-l to disable the inliner. That may reduce the memory
>>> requirements, though of course the generated code will be worse. That
>>> may not matter for your case.
>>>
>>> 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...@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] Compiling a really really large package
It does matter for my use case, but not for these first steps. Thanks. I think still, practically, I need to reduce the code size unfortunately. On Monday, January 9, 2017 at 12:24:36 PM UTC-6, Ian Lance Taylor wrote: > > On Mon, Jan 9, 2017 at 9:00 AM, > wrote: > > I have a really really large package of code that was generated via a > code > > generator. Granted the main code that references it I expect to remove a > lot > > via DCE or something so the binaries wouldn't be extreme. The code is > > > 140MB in the single package which I know sounds extreme. Let's ignore > > practical solutions like reducing code size. I have attempted to compile > on > > my Windows machine and the compile process just runs out of memory and > is > > unable to allocate anymore. I tried on a 4G VM w/ 8G swap and after > almost > > two hours it just gets killed (e.g. "go build example.com/pkg: > > /usr/local/go/pkg/tool/linux_amd64/compile: signal: killed"). > > > > This is with Go 1.7, I have not tested with Go 1.8 but will shortly. I > was > > hoping the compiler would be able to scale, even on a single package, > where > > it could stream the compilation. Are there any flags I should pass to go > > build to make it use less RAM? Is there an effective upper limit on > package > > size or any plans to make the compiler not use linearly-more memory > based on > > code size? I can give instructions on how to build this extreme amount > of > > code too if anyone else wants to try. > > There has been some work on improving the compilation of very large > packages in Go 1.8. I expect that more work needs to be done. > > You can try compiling with -gcflags=-N to disable the optimizers and > -gcflags=-l to disable the inliner. That may reduce the memory > requirements, though of course the generated code will be worse. That > may not matter for your case. > > 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.
[go-nuts] Compiling a really really large package
I have a really really large package of code that was generated via a code generator. Granted the main code that references it I expect to remove a lot via DCE or something so the binaries wouldn't be extreme. The code is > 140MB in the single package which I know sounds extreme. Let's ignore practical solutions like reducing code size. I have attempted to compile on my Windows machine and the compile process just runs out of memory and is unable to allocate anymore. I tried on a 4G VM w/ 8G swap and after almost two hours it just gets killed (e.g. "go build example.com/pkg: /usr/local/go/pkg/tool/linux_amd64/compile: signal: killed"). This is with Go 1.7, I have not tested with Go 1.8 but will shortly. I was hoping the compiler would be able to scale, even on a single package, where it could stream the compilation. Are there any flags I should pass to go build to make it use less RAM? Is there an effective upper limit on package size or any plans to make the compiler not use linearly-more memory based on code size? I can give instructions on how to build this extreme amount of code too if anyone else wants to try. Thanks -- 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] Thinking OO virtual function in Go
Sorry, didn't read the whole thread, but here's how I tackled inheritance in my cross compiler: https://play.golang.org/p/UDp7nSLyl2. Granted, I am unsure about the unsafe thing, but the concept of a "method dispatcher" is likely what you need. On Wednesday, November 23, 2016 at 11:09:03 AM UTC-6, Nick Patavalis wrote: > > > On Wednesday, November 23, 2016 at 5:17:11 PM UTC+2, Tong Sun wrote: >> >> Can you make it work on play.golang.org, from this code >> https://play.golang.org/p/QjCtD9rGpa, according to your plan? >> > > For this specific example, something like this: > https://play.golang.org/p/FsorWRaLKk > > /npat > > -- 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: What lead to the versionning debate?
On Saturday, July 30, 2016 at 1:43:36 AM UTC+2, Dave Cheney wrote: > > How about a tag? which developers should be doing as part of any mature > release process. Sure, a tag may be possible. I thought timestamp because it is easily generated by a machine as well as parsable, with a well defined semantic and ever-increasing. Anything that share these features would do I guess. On Saturday, July 30, 2016 at 1:44:10 AM UTC+2, Gregory Golberg wrote: > > What is wrong with using git submodules inside the vendor directory, > submodules pointing to the tag/revision of your choice? > > I think it's the fact that it locks people into a single version control system. The tooling should ideally remain agnostic for forward-compatibility. > On Friday, July 29, 2016 at 10:24:20 AM UTC-7, Chad wrote: >> >> To be more precise, I am not thinking about a package manager but rather >> more of a kind of package registration interface. A bit like godoc. But >> working by submissions of vcs hosts links (thus allowing mirror links). >> >> Backward compatibility requirements are making things simple already: the >> latest "revision" should have the priority. >> >> On Friday, July 29, 2016 at 6:33:28 PM UTC+2, Chad wrote: >>> >>> Oh I see now. I guess we need something inbetween go get and the >>> different vcs to register and timestamp a package each time it is declared >>> as having been updated. (would still be vcs agnostic though, it's just to >>> timestamp the package files) >>> >>> Would make releasing a package a bit more of a manual process but it >>> could be a good thing. >>> >>> The tooling should be able then to decide up on the latest vendored >>> package to use. >>> >>> That would also decouple the import paths from "github" as is currently >>> often the case. >>> >>> On Friday, July 29, 2016 at 2:47:20 AM UTC+2, Dave Cheney wrote: >>>> >>>> Yes, to use the vendor/ feature project authors need to flatten all >>>> their dependencies into a single, top level, vendor/ folder. This is >>>> currently difficult as there is no common way to look at two copies of the >>>> same source code and decode if there are the same, and if not, which >>>> should >>>> take priority. >>> >>> -- 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: What lead to the versionning debate?
To be more precise, I am not thinking about a package manager but rather more of a kind of package registration interface. A bit like godoc. But working by submissions of vcs hosts links (thus allowing mirror links). Backward compatibility requirements are making things simple already: the latest "revision" should have the priority. On Friday, July 29, 2016 at 6:33:28 PM UTC+2, Chad wrote: > > Oh I see now. I guess we need something inbetween go get and the different > vcs to register and timestamp a package each time it is declared as having > been updated. (would still be vcs agnostic though, it's just to timestamp > the package files) > > Would make releasing a package a bit more of a manual process but it could > be a good thing. > > The tooling should be able then to decide up on the latest vendored > package to use. > > That would also decouple the import paths from "github" as is currently > often the case. > > On Friday, July 29, 2016 at 2:47:20 AM UTC+2, Dave Cheney wrote: >> >> Yes, to use the vendor/ feature project authors need to flatten all their >> dependencies into a single, top level, vendor/ folder. This is currently >> difficult as there is no common way to look at two copies of the same >> source code and decode if there are the same, and if not, which should take >> priority. > > -- 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: What lead to the versionning debate?
To be more precise, I am not thinking about a package manager but rather more of a kind of package registration interface. A bit like godoc. But working by submissions of vcs links (thus allowing mirror links). Backward compatibility requirements are making things simple already: the latest "revision" should have the priority. On Friday, July 29, 2016 at 6:33:28 PM UTC+2, Chad wrote: > > Oh I see now. I guess we need something inbetween go get and the different > vcs to register and timestamp a package each time it is declared as having > been updated. (would still be vcs agnostic though, it's just to timestamp > the package files) > > Would make releasing a package a bit more of a manual process but it could > be a good thing. > > The tooling should be able then to decide up on the latest vendored > package to use. > > That would also decouple the import paths from "github" as is currently > often the case. > > On Friday, July 29, 2016 at 2:47:20 AM UTC+2, Dave Cheney wrote: >> >> Yes, to use the vendor/ feature project authors need to flatten all their >> dependencies into a single, top level, vendor/ folder. This is currently >> difficult as there is no common way to look at two copies of the same >> source code and decode if there are the same, and if not, which should take >> priority. > > -- 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: What lead to the versionning debate?
Oh I see now. I guess we need something inbetween go get and the different vcs to register and timestamp a package each time it is declared as having been updated. (would still be vcs agnostic though, it's just to timestamp the package files) Would make releasing a package a bit more of a manual process but it could be a good thing. The tooling should be able then to decide up on the latest vendored package to use. That would also decouple the import paths from "github" as is currently often the case. On Friday, July 29, 2016 at 2:47:20 AM UTC+2, Dave Cheney wrote: > > Yes, to use the vendor/ feature project authors need to flatten all their > dependencies into a single, top level, vendor/ folder. This is currently > difficult as there is no common way to look at two copies of the same > source code and decode if there are the same, and if not, which should take > priority. -- 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: What lead to the versionning debate?
My reasoning was flawed. (also, I generally mean "one" when I use "we" :) I think you're right with the project based approach in gb (for people interested in reproducible builds). I think that the pkg path issue (that leads to type equality issue) may be simply solved by having the vendor directory at the root of the project directory. (so no vendor directory per library) Any conflict caused by the evolution of a vendored package API would be stemming from the API surface having been augmented. That should trigger an update of the vendored library. (If the author did not keep with the backward compatibility requirement, then that would be a breach of versioning as Go defines it.) Maybe I am overlooking something still. On Friday, July 29, 2016 at 1:46:26 AM UTC+2, Dave Cheney wrote: > > Who is we ? You and me ? > > On Friday, 29 July 2016 08:50:47 UTC+10, Chad wrote: >> >> So if we decided that vendoring always used HEAD, that would ideally >> force people to have stable APIs (plus, why vendor an unstable/ in-flight >> API anyway) >> >> Couldn't it enable a change of behaviour for go get when a vendor >> directory is detected and solve some of the issues related to type equality >> (by having a single pkg path for a vendored package) ? >> >> >> >> On Friday, July 29, 2016 at 12:14:02 AM UTC+2, Dave Cheney wrote: >>> >>> Yes, exactly. >> >> -- 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: What lead to the versionning debate?
Actually, nevermind. I was thinking about libraries using vendoring. But that's probably a misuse. On Friday, July 29, 2016 at 12:50:47 AM UTC+2, Chad wrote: > > So if we decided that vendoring always used HEAD, that would ideally force > people to have stable APIs (plus, why vendor an unstable/ in-flight API > anyway) > > Couldn't it enable a change of behaviour for go get when a vendor > directory is detected and solve some of the issues related to type equality > (by having a single pkg path for a vendored package) ? > > > > On Friday, July 29, 2016 at 12:14:02 AM UTC+2, Dave Cheney wrote: >> >> Yes, exactly. > > -- 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: What lead to the versionning debate?
So if we decided that vendoring always used HEAD, that would ideally force people to have stable APIs (plus, why vendor an unstable/ in-flight API anyway) Couldn't it enable a change of behaviour for go get when a vendor directory is detected and solve some of the issues related to type equality (by having a single pkg path for a vendored package) ? On Friday, July 29, 2016 at 12:14:02 AM UTC+2, Dave Cheney wrote: > > Yes, exactly. -- 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: What lead to the versionning debate?
Hi Dave, Thank you for the link. >From the discussions I have seen so far, it seems to me that there is a conflation between the notions of version and revision. The go tooling AND language remains unaware of revisions indeed, which would be the role of the source control system (often git nowadays but who knows in the future). It introduces decoupling here which I guess is welcomed for forward compatibility with source control systems. Is that what people find problematic? (no automatic way to retrieve a package at a given revision?) I understand vendoring as a way to circumvent the reliance on the social contract that fetching HEAD will never be API breaking. Is that right? On Thursday, July 28, 2016 at 11:49:51 PM UTC+2, Dave Cheney wrote: > > Hello, > > You're pretty late to the discussion. Here's some background reading. > > https://getgb.io/rationale/ > > Dave > > -- 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] What lead to the versionning debate?
Just wondering, Because as of now, in Go, the Pkg path is the version and for reproducible builds, your source/version control is probably more suited to handle the task. Or are there drawbacks to that? -- 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: Go can't alloc custom objects from byte slice's memory address?
You could create an array per object type (which would be the aggregate underlying array of your slices) and use a sync.Pool for each type as the previous post mentions. On Saturday, July 9, 2016 at 8:40:15 AM UTC+2, Arthur wrote: > > the program need parser SQL, and generate the AST node allocates many > temporary object. > after compile, all AST objects can be recycled. > pprof show parser take 14% of the whole object allocation, and 40% CPU > time is waste on GC scan related. > GC is good, but not free. > > 在 2016年7月9日星期六 UTC+8下午2:25:05，Chad写道： >> >> Create an array instead. But with the progress of the GC algorithm... not >> sure you should encounter such GC pressure. >> >> On Saturday, July 9, 2016 at 7:11:49 AM UTC+2, Arthur wrote: >>> >>> my program allocates many different kinds of small object, and that >>> gives GC a lot pressure. >>> so I wan't to make a big slice and split object from it manually. >>> >>> block = make([]byte, 30*1024) >>> myObj := (*myObjType)(unsafe.Pointer(&block[offset])) >>> >>> I write a simple allocator to do it, but I meet strange panic. >>> so my question is, can't go alloc custom objects from byte slice's >>> memory address? >>> >> -- 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: Go can't alloc custom objects from byte slice's memory address?
Create an array instead. But with the progress of the GC algorithm... not sure you should encounter such GC pressure. On Saturday, July 9, 2016 at 7:11:49 AM UTC+2, Arthur wrote: > > my program allocates many different kinds of small object, and that gives > GC a lot pressure. > so I wan't to make a big slice and split object from it manually. > > block = make([]byte, 30*1024) > myObj := (*myObjType)(unsafe.Pointer(&block[offset])) > > I write a simple allocator to do it, but I meet strange panic. > so my question is, can't go alloc custom objects from byte slice's memory > address? > -- 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: log.Logger, Why is this not an interface?
It's funny because I have been thinking about logging lately. And I believe that the data/message, with a chosen formatting, is more important here. A mere function with an interface argument could even be sufficient. On Friday, July 8, 2016 at 6:33:37 AM UTC+2, Zachary Gershman wrote: > > Hey All, > > Originally asked on twitter but a more long-form medium is required to > answer this question. I've recently been working on adding logging to a > library and have been replacing what was once a custom logging interface > with just *log.Logger. In so doing, I removed my ability to mock the logger > (if I choose) and that steered me towards not testing / test-driving any of > my logging output. > > Walking down this path led me to these specific questions: > > 1. Does any one REALLY test whether their app logs specific log lines > (when logging is not your the apps primary function) > 2. Why isn't log.Logger just an interface instead of a struct (or why > isn't there a LogWriter interface that specifies a few of the log packages > multiple methods) > 3. What has been the litmus test for when the stdlib will provide an > interface (like io.Writer) > -- 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] Vendored trace package causes panic because of implicit handlers
Seems to me that not leaking API outside of the package it is being used is a must for a vendored package. -- 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] Vendored trace package causes panic because of implicit handlers
On Tuesday, July 5, 2016 at 8:38:11 PM UTC+2, Peter Bourgon wrote: > > > > Exception to the rule: if a library vendors dependencies that don't > leak into the public API, and don't have potentially crashy func > inits, then it's OK to leave the vendor directory in place. > > This is of course completely unsatisfying and I hope it will be > addressed by the core team as soon as possible. > > As an aside, wouldn't that require to address the larger issue of versioning? The reasoning being that if you decide to vendor, you're basically freezing the version of the dependency you're using. I also expect that issue (and similiar ones) to come up https://golang.org/issue/16209 -- 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: A proposal for generic in go
Hehe, perhaps. But I am not sure that it makes people much slower if that assertion is even true. The thing being that, what is more important for an application algorithm? The data or the datastructure ? I would tend to think that the data is more important. The choice of datastructure is often about computation speed. For most application side algorithms/protocols etc, we already have most of the building blocks we need. On Tuesday, July 5, 2016 at 12:54:31 PM UTC+2, Mandolyte wrote: > > On Saturday, July 2, 2016 at 9:12:54 AM UTC-4, Chad wrote: >> >> >> >> The appeal of generics is probably a false appeal. >> >> Then, if you accept the trilemma described at > http://research.swtch.com/generic, that puts you in favor of "slow > programmers"... just kidding. I went back to read all the comments from > that blog post and found that it could have been written yesterday. Not > much has changed since 2009. One commenter Rivorus > <http://www.blogger.com/profile/03014588465653251422> is very eloquent, > favoring generics and points convincingly to the Boost Graph Library as why > they are necessary. Others not so much. Pretty much like every thread on > this topic when it comes up. > > But I think the key is that Go's target of server side development rarely > needs generics (think of Docker, Kubernetics, web server, etc.). However, > just last April, Ian Lance Taylor stated forcefully "Go should support some > form of generic programming. Generic programming enables the representation > of algorithms and data structures in a generic form, with concrete elements > of the code (such as types) factored out. It means the ability to express > algorithms with minimal assumptions about data structures, and vice-versa." > at https://github.com/golang/proposal/blob/master/design/15292-generics.md > . > > This leads me to conclude that there are whole areas of software > development that Go could impact significantly if it introduced generics. I > think someone already pointed this out earlier in the thread, that this > area is one of Libraries, Frameworks. This is an area of some controversy > in the Go community. See, for instance, Doug Cheney's blog post at > http://dave.cheney.net/2014/10/26/go-frameworks-and-ludditry. > > But I'm with Ian on this point. Go needs it, but I'm content to wait for > it to be done well. > > -- 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] Re: Relaxing rules on slice comparison: would it make sense?
I realize that the issue might be about changing/ adding a builtin: - either add a builtin deep value Comparison function (via reflection) - or add a snapshot type refinement which triggers the allocation of an immutable copy of a reference type (and we would recover the behaviour of the string implementation which is a special case of []byte snapshot, i.e. a value type*) I would still expect the behaviour previously mentioned for the "==" operator. (*) I keep using reference/value type terminology but it is indeed slightly tricky. But for lack of a better one... -- 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] Re: Relaxing rules on slice comparison: would it make sense?
Actually that's my mistake. It is spec'ed but not in the bullet points. https://golang.org/ref/spec#Comparison_operators Still, I find this hairy. On Monday, July 4, 2016 at 12:52:11 AM UTC+2, Chad wrote: > > To illustrate. > I think that an issue should be raised. > > https://play.golang.org/p/eiwG-4vsnJ > > > > -- 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] Re: Relaxing rules on slice comparison: would it make sense?
To illustrate. I think that an issue should be raised. https://play.golang.org/p/eiwG-4vsnJ -- 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] Re: Relaxing rules on slice comparison: would it make sense?
On Monday, July 4, 2016 at 12:09:57 AM UTC+2, as@gmail.com wrote: > > I wish I could be pointed to such discussion. >> > > It was briefly discussed in *The Go Programming Language *book by Donovan > & Kernighan (p 132) > > *:* > >> An analogous “shallow” equality test for slices could be useful, and it >> would solve the problem with maps, but the inconsistent treatment of slices >> and arrays by the == operator would be confusing. The safest choice is to >> disallow slice comparisons altogether. > > A claim I find safe to be in disagreement with. > > Given this program, how would you modify it to include interfaces? > > https://play.golang.org/p/9-rhDCZol_ > Starbytes is a pointer to a slice. It does not make a lot of sense to begin with. I am pointing out the fact that if you have interfaces holding a slice, the current behaviour is not specified. (as in the Go's spec). That's a bug. -- 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] Re: Relaxing rules on slice comparison: would it make sense?
I wish I could be pointed to such discussion. > The language authors omitted this functionality for a reason. One of the > reasons is that arrays and slices are similar, and changing their > comparison semantics seemed confusing. > https://blog.golang.org/slices specifically mentions that arrays and slices are not similar. The spec does as well. Currently, slices do NOT compare. I am simply arguing that they could very logically. The "==" operator is only overloaded in the case of strings currently but that's truly an implementation detail. Strings are values but their implementation is of a reference type. To get the value behaviour back, the comparison is weakened to only take into account the underlying array values and not where they are located. This probably for optimisation purposes. Other than that, there is a whole consistency to the language and how it works. I simply would like that consistency extended. My main argument is that without specifying the logical "comparison" behaviour for all reference types,* interface comparisons become unsafe*. It's perhaps even a *bug*. N.B. I gave my definition of a reference type which is the definition I would choose for Go. It does not have to be identical to what is found in other languages. In any case, there probably needs to be a way to distinguish between types that hold a reference to another datastructure from those that don'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.
Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?
Pardon?
On Sunday, July 3, 2016 at 8:13:30 PM UTC+2, as@gmail.com wrote:
>
> Hardcoded proofs should be assigned well-named identifiers. If you ever
> have to alter them, you don't want to be rummaging around your lemmas and
> corollaries.
>
> On Sunday, July 3, 2016 at 5:32:26 AM UTC-7, Chad wrote:
>>
>> Ok. That "haha" was merely to show that no animosity was borne. And also
>> because you didn't really answer the question as I asked (by quoting the
>> spec) which I found funny.
>>
>> Alas, I guess we couldn't see eye to eye.
>>
>> But chill a little bit. I have given all the hardcoded proofs and people
>> have just given me *feelings* about what they thought should be right. I
>> think I have the right to disagree.
>>
>> Anyway, I can only wish you good continuation. :)
>>
>>
>> On Sunday, July 3, 2016 at 2:04:47 PM UTC+2, Florin Pățan wrote:
>>>
>>> I'm sorry but your attitude is counterproductive to the discussion.
>>> "haha" what? I told you I see your point, I think I know the specs very
>>> well, thank you for the link.
>>> However, you seem incapable of accepting, despite an number of others
>>> saying the contrary, despite, given a reasonable example where even the
>>> standard library gets this "wrong" (according to you, according to me it's
>>> exactly as it should be).
>>> You've been explained several times that both point of views hold valid
>>> arguments so why do you insist your point of view is the only correct one
>>> and everyone else is wrong?
>>> The authors of the language which have far more experience that me (I
>>> can't speak for your experience or others), couldn't get to an agreement on
>>> how this should work so they took the best decision, let the user deal with
>>> this according to their individual needs.
>>> I'll stop following this thread / replying as it's pointless to do so at
>>> this point.
>>> Good luck proving everyone else is wrong and you know better.
>>>
>>> On Sunday, July 3, 2016 at 12:47:12 PM UTC+1, Chad wrote:
>>>>
>>>> Ok, Let me help you out haha :)
>>>>
>>>> Here is the definition of a slice. It is not a container.
>>>> https://golang.org/ref/spec#Slice_types
>>>>
>>>> I am not inventing things.
>>>>
>>>> I know what people on this thread said, but that's their misconception.
>>>>
>>>> On Sunday, July 3, 2016 at 1:40:46 PM UTC+2, Florin Pățan wrote:
>>>>>
>>>>> As you pointed out, Printf() should follow the ref spec but that
>>>>> doesn't happen because some humans don't perceive this accuracy as
>>>>> necessary or maybe because the way to resonate about slices / arrays is
>>>>> as
>>>>> containers for the actual values.
>>>>> Thus we have Printf working as it does (and %p will indeed print the
>>>>> memory address of the slice type).
>>>>>
>>>>> I would definitely want to be able to compare []int{1, 2, 3} with
>>>>> ([]int{1, 2, 3, 4, 5})[:3] and result in equality (given here for example
>>>>> purposes but think of them as coming from different sources)
>>>>> Apparently you don't, and that's fine.
>>>>>
>>>>> That's exactly why the compiler only allows comparison with nil, to
>>>>> force the user to think about that should be compared, not do it by
>>>>> default
>>>>> and have potential hidden issues that might be uncovered too late in the
>>>>> process.
>>>>>
>>>>> On Sunday, July 3, 2016 at 12:20:17 PM UTC+1, Chad wrote:
>>>>>>
>>>>>> In fact, that is somewhat my fault.
>>>>>>
>>>>>> I should ask:
>>>>>>
>>>>>> What is a slice?
>>>>>> What is an array?
>>>>>>
>>>>>> Spoiler: a slice is a reference type in its "wikipedia-ish"
>>>>>> definition (auto-dereferencing) which is the reason you observe such a
>>>>>> result in the playground.
>>>>>>
>>>>>> On Sunday, July 3, 2016 at 1:12:17 PM UTC+2, Chad wrote:
>>>>>>>
>>>>>>> No. You should not get it from here. You should get the answer from
Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?
Ok. That "haha" was merely to show that no animosity was borne. And also
because you didn't really answer the question as I asked (by quoting the
spec) which I found funny.
Alas, I guess we couldn't see eye to eye.
But chill a little bit. I have given all the hardcoded proofs and people
have just given me *feelings* about what they thought should be right. I
think I have the right to disagree.
Anyway, I can only wish you good continuation. :)
On Sunday, July 3, 2016 at 2:04:47 PM UTC+2, Florin Pățan wrote:
>
> I'm sorry but your attitude is counterproductive to the discussion.
> "haha" what? I told you I see your point, I think I know the specs very
> well, thank you for the link.
> However, you seem incapable of accepting, despite an number of others
> saying the contrary, despite, given a reasonable example where even the
> standard library gets this "wrong" (according to you, according to me it's
> exactly as it should be).
> You've been explained several times that both point of views hold valid
> arguments so why do you insist your point of view is the only correct one
> and everyone else is wrong?
> The authors of the language which have far more experience that me (I
> can't speak for your experience or others), couldn't get to an agreement on
> how this should work so they took the best decision, let the user deal with
> this according to their individual needs.
> I'll stop following this thread / replying as it's pointless to do so at
> this point.
> Good luck proving everyone else is wrong and you know better.
>
> On Sunday, July 3, 2016 at 12:47:12 PM UTC+1, Chad wrote:
>>
>> Ok, Let me help you out haha :)
>>
>> Here is the definition of a slice. It is not a container.
>> https://golang.org/ref/spec#Slice_types
>>
>> I am not inventing things.
>>
>> I know what people on this thread said, but that's their misconception.
>>
>> On Sunday, July 3, 2016 at 1:40:46 PM UTC+2, Florin Pățan wrote:
>>>
>>> As you pointed out, Printf() should follow the ref spec but that doesn't
>>> happen because some humans don't perceive this accuracy as necessary or
>>> maybe because the way to resonate about slices / arrays is as containers
>>> for the actual values.
>>> Thus we have Printf working as it does (and %p will indeed print the
>>> memory address of the slice type).
>>>
>>> I would definitely want to be able to compare []int{1, 2, 3} with
>>> ([]int{1, 2, 3, 4, 5})[:3] and result in equality (given here for example
>>> purposes but think of them as coming from different sources)
>>> Apparently you don't, and that's fine.
>>>
>>> That's exactly why the compiler only allows comparison with nil, to
>>> force the user to think about that should be compared, not do it by default
>>> and have potential hidden issues that might be uncovered too late in the
>>> process.
>>>
>>> On Sunday, July 3, 2016 at 12:20:17 PM UTC+1, Chad wrote:
>>>>
>>>> In fact, that is somewhat my fault.
>>>>
>>>> I should ask:
>>>>
>>>> What is a slice?
>>>> What is an array?
>>>>
>>>> Spoiler: a slice is a reference type in its "wikipedia-ish" definition
>>>> (auto-dereferencing) which is the reason you observe such a result in the
>>>> playground.
>>>>
>>>> On Sunday, July 3, 2016 at 1:12:17 PM UTC+2, Chad wrote:
>>>>>
>>>>> No. You should not get it from here. You should get the answer from
>>>>> the spec. Let alone the fact that the implementation should ideally
>>>>> follow
>>>>> the spec and not the reverse.
>>>>>
>>>>> On Sunday, July 3, 2016 at 1:03:44 PM UTC+2, Florin Pățan wrote:
>>>>>>
>>>>>> If I look at what %v means, print out the values of various types in
>>>>>> Go, according to https://golang.org/pkg/fmt/ then I believe that
>>>>>> this holds the answer: https://play.golang.org/p/GiLckoBDxa
>>>>>>
>>>>>> On Sunday, July 3, 2016 at 11:33:01 AM UTC+1, Chad wrote:
>>>>>>>
>>>>>>> Not for comparison.
>>>>>>>
>>>>>>> I am just asking what is the value of a slice and what is the value
>>>>>>> of an array.
>>>>>>>
>>>>>>> Remember that there is no slice comparison that has b
Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?
Ok, Let me help you out haha :)
Here is the definition of a slice. It is not a container.
https://golang.org/ref/spec#Slice_types
I am not inventing things.
I know what people on this thread said, but that's their misconception.
On Sunday, July 3, 2016 at 1:40:46 PM UTC+2, Florin Pățan wrote:
>
> As you pointed out, Printf() should follow the ref spec but that doesn't
> happen because some humans don't perceive this accuracy as necessary or
> maybe because the way to resonate about slices / arrays is as containers
> for the actual values.
> Thus we have Printf working as it does (and %p will indeed print the
> memory address of the slice type).
>
> I would definitely want to be able to compare []int{1, 2, 3} with
> ([]int{1, 2, 3, 4, 5})[:3] and result in equality (given here for example
> purposes but think of them as coming from different sources)
> Apparently you don't, and that's fine.
>
> That's exactly why the compiler only allows comparison with nil, to force
> the user to think about that should be compared, not do it by default and
> have potential hidden issues that might be uncovered too late in the
> process.
>
> On Sunday, July 3, 2016 at 12:20:17 PM UTC+1, Chad wrote:
>>
>> In fact, that is somewhat my fault.
>>
>> I should ask:
>>
>> What is a slice?
>> What is an array?
>>
>> Spoiler: a slice is a reference type in its "wikipedia-ish" definition
>> (auto-dereferencing) which is the reason you observe such a result in the
>> playground.
>>
>> On Sunday, July 3, 2016 at 1:12:17 PM UTC+2, Chad wrote:
>>>
>>> No. You should not get it from here. You should get the answer from the
>>> spec. Let alone the fact that the implementation should ideally follow the
>>> spec and not the reverse.
>>>
>>> On Sunday, July 3, 2016 at 1:03:44 PM UTC+2, Florin Pățan wrote:
>>>>
>>>> If I look at what %v means, print out the values of various types in
>>>> Go, according to https://golang.org/pkg/fmt/ then I believe that this
>>>> holds the answer: https://play.golang.org/p/GiLckoBDxa
>>>>
>>>> On Sunday, July 3, 2016 at 11:33:01 AM UTC+1, Chad wrote:
>>>>>
>>>>> Not for comparison.
>>>>>
>>>>> I am just asking what is the value of a slice and what is the value of
>>>>> an array.
>>>>>
>>>>> Remember that there is no slice comparison that has been spec'ed so
>>>>> far.
>>>>>
>>>>> On Sunday, July 3, 2016 at 12:24:05 PM UTC+2, Florin Pățan wrote:
>>>>>>
>>>>>> For []T the value of a slice for the purpose of comparison would be
>>>>>> each individual value compared against each-other (ofc maybe comparing
>>>>>> the
>>>>>> length first as an optimization).
>>>>>> Same goes for an array.
>>>>>>
>>>>>> And again, you are missing the whole point. Both me and you are wrong
>>>>>> in each-others points of view.
>>>>>> Just accept this.
>>>>>>
>>>>>> On Sunday, July 3, 2016 at 11:19:48 AM UTC+1, Chad wrote:
>>>>>>>
>>>>>>> What's the value of a slice?
>>>>>>>
>>>>>>> What's the value of an array?
>>>>>>>
>>>>>>> On Sunday, July 3, 2016 at 12:05:38 PM UTC+2, Florin Pățan wrote:
>>>>>>>>
>>>>>>>> If the type is *[]T then comparing memory addresses make sense to
>>>>>>>> see if both terms point to the same memory address.
>>>>>>>> If the type is []T then comparing memory addresses doesn't make
>>>>>>>> sense as I'd expect to compare values.
>>>>>>>> Finally, if the type is []*T then I'd still expect to compare
>>>>>>>> values (even if this is inconsistent with the above two rules), mainly
>>>>>>>> because I'm usually interested in the values a slice holds.
>>>>>>>>
>>>>>>>> And that's exactly why Ian and others said this is complicated to
>>>>>>>> define as different users expect different outcomes.
>>>>>>>> So rather than deal with this, in an auto-magic way, better let the
>>>>>>>> users deal with it as they see fit from case to case.
>>>>>>>&
Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?
In fact, that is somewhat my fault. I should ask: What is a slice? What is an array? Spoiler: a slice is a reference type in its "wikipedia-ish" definition (auto-dereferencing) which is the reason you observe such a result in the playground. On Sunday, July 3, 2016 at 1:12:17 PM UTC+2, Chad wrote: > > No. You should not get it from here. You should get the answer from the > spec. Let alone the fact that the implementation should ideally follow the > spec and not the reverse. > > On Sunday, July 3, 2016 at 1:03:44 PM UTC+2, Florin Pățan wrote: >> >> If I look at what %v means, print out the values of various types in Go, >> according to https://golang.org/pkg/fmt/ then I believe that this holds >> the answer: https://play.golang.org/p/GiLckoBDxa >> >> On Sunday, July 3, 2016 at 11:33:01 AM UTC+1, Chad wrote: >>> >>> Not for comparison. >>> >>> I am just asking what is the value of a slice and what is the value of >>> an array. >>> >>> Remember that there is no slice comparison that has been spec'ed so far. >>> >>> On Sunday, July 3, 2016 at 12:24:05 PM UTC+2, Florin Pățan wrote: >>>> >>>> For []T the value of a slice for the purpose of comparison would be >>>> each individual value compared against each-other (ofc maybe comparing the >>>> length first as an optimization). >>>> Same goes for an array. >>>> >>>> And again, you are missing the whole point. Both me and you are wrong >>>> in each-others points of view. >>>> Just accept this. >>>> >>>> On Sunday, July 3, 2016 at 11:19:48 AM UTC+1, Chad wrote: >>>>> >>>>> What's the value of a slice? >>>>> >>>>> What's the value of an array? >>>>> >>>>> On Sunday, July 3, 2016 at 12:05:38 PM UTC+2, Florin Pățan wrote: >>>>>> >>>>>> If the type is *[]T then comparing memory addresses make sense to see >>>>>> if both terms point to the same memory address. >>>>>> If the type is []T then comparing memory addresses doesn't make sense >>>>>> as I'd expect to compare values. >>>>>> Finally, if the type is []*T then I'd still expect to compare values >>>>>> (even if this is inconsistent with the above two rules), mainly because >>>>>> I'm >>>>>> usually interested in the values a slice holds. >>>>>> >>>>>> And that's exactly why Ian and others said this is complicated to >>>>>> define as different users expect different outcomes. >>>>>> So rather than deal with this, in an auto-magic way, better let the >>>>>> users deal with it as they see fit from case to case. >>>>>> >>>>>> On Sunday, July 3, 2016 at 10:53:39 AM UTC+1, Chad wrote: >>>>>>> >>>>>>> Which is why it should be formalized. >>>>>>> >>>>>>> Where is the inconsistency between slices and arrays? >>>>>>> Why do people even think that a slice need to behave like an array >>>>>>> wrt equality, were it introduced? >>>>>>> >>>>>>> A slice is not an array! >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sunday, July 3, 2016 at 11:36:44 AM UTC+2, as@gmail.com >>>>>>> wrote: >>>>>>>> >>>>>>>> Relaxing unformalized behavior makes little sense to me. Explaining >>>>>>>> why equality is inconsistent between slices and arrays is not >>>>>>>> something I >>>>>>>> want to do either. >>>>>>>> >>>>>>>> >>>>>>>> On Sunday, July 3, 2016 at 1:40:19 AM UTC-7, Chad wrote: >>>>>>>>> >>>>>>>>> Rob and Robert actually wrote that this area of the spec needs >>>>>>>>> more work... >>>>>>>>> Otherwise, the behaviour of maps, slices and funcs cannot be fully >>>>>>>>> explained. >>>>>>>>> >>>>>>>>> On Sunday, July 3, 2016 at 7:25:31 AM UTC+2, as@gmail.com >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Go does not have reference types. As far as I know, the word was >>>>>>>>>> purposefully removed from the spec to remove the ambiguity >>>>>>>>>> surrounding the >>>>>>>>>> word. >>>>>>>>>> >>>>>>>>>> https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> @Martin >>>>>>>>> >>>>>>>>> As I've mentioned earlier, one ought to be careful about false >>>>>>>>> friends from other languages. >>>>>>>>> I am not sure I understand what you mean by: >>>>>>>>> >>>>>>>>> if the name field is changed after the call >>>>>>>>> >>>>>>>>> >>>>>>>>> -- 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] Re: Relaxing rules on slice comparison: would it make sense?
No. You should not get it from here. You should get the answer from the spec. Let alone the fact that the implementation should ideally follow the spec and not the reverse. On Sunday, July 3, 2016 at 1:03:44 PM UTC+2, Florin Pățan wrote: > > If I look at what %v means, print out the values of various types in Go, > according to https://golang.org/pkg/fmt/ then I believe that this holds > the answer: https://play.golang.org/p/GiLckoBDxa > > On Sunday, July 3, 2016 at 11:33:01 AM UTC+1, Chad wrote: >> >> Not for comparison. >> >> I am just asking what is the value of a slice and what is the value of an >> array. >> >> Remember that there is no slice comparison that has been spec'ed so far. >> >> On Sunday, July 3, 2016 at 12:24:05 PM UTC+2, Florin Pățan wrote: >>> >>> For []T the value of a slice for the purpose of comparison would be each >>> individual value compared against each-other (ofc maybe comparing the >>> length first as an optimization). >>> Same goes for an array. >>> >>> And again, you are missing the whole point. Both me and you are wrong in >>> each-others points of view. >>> Just accept this. >>> >>> On Sunday, July 3, 2016 at 11:19:48 AM UTC+1, Chad wrote: >>>> >>>> What's the value of a slice? >>>> >>>> What's the value of an array? >>>> >>>> On Sunday, July 3, 2016 at 12:05:38 PM UTC+2, Florin Pățan wrote: >>>>> >>>>> If the type is *[]T then comparing memory addresses make sense to see >>>>> if both terms point to the same memory address. >>>>> If the type is []T then comparing memory addresses doesn't make sense >>>>> as I'd expect to compare values. >>>>> Finally, if the type is []*T then I'd still expect to compare values >>>>> (even if this is inconsistent with the above two rules), mainly because >>>>> I'm >>>>> usually interested in the values a slice holds. >>>>> >>>>> And that's exactly why Ian and others said this is complicated to >>>>> define as different users expect different outcomes. >>>>> So rather than deal with this, in an auto-magic way, better let the >>>>> users deal with it as they see fit from case to case. >>>>> >>>>> On Sunday, July 3, 2016 at 10:53:39 AM UTC+1, Chad wrote: >>>>>> >>>>>> Which is why it should be formalized. >>>>>> >>>>>> Where is the inconsistency between slices and arrays? >>>>>> Why do people even think that a slice need to behave like an array >>>>>> wrt equality, were it introduced? >>>>>> >>>>>> A slice is not an array! >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Sunday, July 3, 2016 at 11:36:44 AM UTC+2, as@gmail.com wrote: >>>>>>> >>>>>>> Relaxing unformalized behavior makes little sense to me. Explaining >>>>>>> why equality is inconsistent between slices and arrays is not something >>>>>>> I >>>>>>> want to do either. >>>>>>> >>>>>>> >>>>>>> On Sunday, July 3, 2016 at 1:40:19 AM UTC-7, Chad wrote: >>>>>>>> >>>>>>>> Rob and Robert actually wrote that this area of the spec needs more >>>>>>>> work... >>>>>>>> Otherwise, the behaviour of maps, slices and funcs cannot be fully >>>>>>>> explained. >>>>>>>> >>>>>>>> On Sunday, July 3, 2016 at 7:25:31 AM UTC+2, as@gmail.com >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Go does not have reference types. As far as I know, the word was >>>>>>>>> purposefully removed from the spec to remove the ambiguity >>>>>>>>> surrounding the >>>>>>>>> word. >>>>>>>>> >>>>>>>>> https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> @Martin >>>>>>>> >>>>>>>> As I've mentioned earlier, one ought to be careful about false >>>>>>>> friends from other languages. >>>>>>>> I am not sure I understand what you mean by: >>>>>>>> >>>>>>>> if the name field is changed after the call >>>>>>>> >>>>>>>> >>>>>>>> -- 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] Re: Relaxing rules on slice comparison: would it make sense?
Not for comparison. I am just asking what is the value of a slice and what is the value of an array. Remember that there is no slice comparison that has been spec'ed so far. On Sunday, July 3, 2016 at 12:24:05 PM UTC+2, Florin Pățan wrote: > > For []T the value of a slice for the purpose of comparison would be each > individual value compared against each-other (ofc maybe comparing the > length first as an optimization). > Same goes for an array. > > And again, you are missing the whole point. Both me and you are wrong in > each-others points of view. > Just accept this. > > On Sunday, July 3, 2016 at 11:19:48 AM UTC+1, Chad wrote: >> >> What's the value of a slice? >> >> What's the value of an array? >> >> On Sunday, July 3, 2016 at 12:05:38 PM UTC+2, Florin Pățan wrote: >>> >>> If the type is *[]T then comparing memory addresses make sense to see if >>> both terms point to the same memory address. >>> If the type is []T then comparing memory addresses doesn't make sense as >>> I'd expect to compare values. >>> Finally, if the type is []*T then I'd still expect to compare values >>> (even if this is inconsistent with the above two rules), mainly because I'm >>> usually interested in the values a slice holds. >>> >>> And that's exactly why Ian and others said this is complicated to define >>> as different users expect different outcomes. >>> So rather than deal with this, in an auto-magic way, better let the >>> users deal with it as they see fit from case to case. >>> >>> On Sunday, July 3, 2016 at 10:53:39 AM UTC+1, Chad wrote: >>>> >>>> Which is why it should be formalized. >>>> >>>> Where is the inconsistency between slices and arrays? >>>> Why do people even think that a slice need to behave like an array wrt >>>> equality, were it introduced? >>>> >>>> A slice is not an array! >>>> >>>> >>>> >>>> >>>> On Sunday, July 3, 2016 at 11:36:44 AM UTC+2, as@gmail.com wrote: >>>>> >>>>> Relaxing unformalized behavior makes little sense to me. Explaining >>>>> why equality is inconsistent between slices and arrays is not something I >>>>> want to do either. >>>>> >>>>> >>>>> On Sunday, July 3, 2016 at 1:40:19 AM UTC-7, Chad wrote: >>>>>> >>>>>> Rob and Robert actually wrote that this area of the spec needs more >>>>>> work... >>>>>> Otherwise, the behaviour of maps, slices and funcs cannot be fully >>>>>> explained. >>>>>> >>>>>> On Sunday, July 3, 2016 at 7:25:31 AM UTC+2, as@gmail.com wrote: >>>>>>> >>>>>>> Go does not have reference types. As far as I know, the word was >>>>>>> purposefully removed from the spec to remove the ambiguity surrounding >>>>>>> the >>>>>>> word. >>>>>>> >>>>>>> https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA >>>>>> >>>>>> >>>>>> >>>>>> @Martin >>>>>> >>>>>> As I've mentioned earlier, one ought to be careful about false >>>>>> friends from other languages. >>>>>> I am not sure I understand what you mean by: >>>>>> >>>>>> if the name field is changed after the call >>>>>> >>>>>> >>>>>> -- 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] Re: Relaxing rules on slice comparison: would it make sense?
What's the value of a slice? What's the value of an array? On Sunday, July 3, 2016 at 12:05:38 PM UTC+2, Florin Pățan wrote: > > If the type is *[]T then comparing memory addresses make sense to see if > both terms point to the same memory address. > If the type is []T then comparing memory addresses doesn't make sense as > I'd expect to compare values. > Finally, if the type is []*T then I'd still expect to compare values (even > if this is inconsistent with the above two rules), mainly because I'm > usually interested in the values a slice holds. > > And that's exactly why Ian and others said this is complicated to define > as different users expect different outcomes. > So rather than deal with this, in an auto-magic way, better let the users > deal with it as they see fit from case to case. > > On Sunday, July 3, 2016 at 10:53:39 AM UTC+1, Chad wrote: >> >> Which is why it should be formalized. >> >> Where is the inconsistency between slices and arrays? >> Why do people even think that a slice need to behave like an array wrt >> equality, were it introduced? >> >> A slice is not an array! >> >> >> >> >> On Sunday, July 3, 2016 at 11:36:44 AM UTC+2, as@gmail.com wrote: >>> >>> Relaxing unformalized behavior makes little sense to me. Explaining why >>> equality is inconsistent between slices and arrays is not something I want >>> to do either. >>> >>> >>> On Sunday, July 3, 2016 at 1:40:19 AM UTC-7, Chad wrote: >>>> >>>> Rob and Robert actually wrote that this area of the spec needs more >>>> work... >>>> Otherwise, the behaviour of maps, slices and funcs cannot be fully >>>> explained. >>>> >>>> On Sunday, July 3, 2016 at 7:25:31 AM UTC+2, as@gmail.com wrote: >>>>> >>>>> Go does not have reference types. As far as I know, the word was >>>>> purposefully removed from the spec to remove the ambiguity surrounding >>>>> the >>>>> word. >>>>> >>>>> https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA >>>> >>>> >>>> >>>> @Martin >>>> >>>> As I've mentioned earlier, one ought to be careful about false friends >>>> from other languages. >>>> I am not sure I understand what you mean by: >>>> >>>> if the name field is changed after the call >>>> >>>> >>>> -- 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] Re: Relaxing rules on slice comparison: would it make sense?
Which is why it should be formalized. Where is the inconsistency between slices and arrays? Why do people even think that a slice need to behave like an array wrt equality, were it introduced? A slice is not an array! On Sunday, July 3, 2016 at 11:36:44 AM UTC+2, as@gmail.com wrote: > > Relaxing unformalized behavior makes little sense to me. Explaining why > equality is inconsistent between slices and arrays is not something I want > to do either. > > > On Sunday, July 3, 2016 at 1:40:19 AM UTC-7, Chad wrote: >> >> Rob and Robert actually wrote that this area of the spec needs more >> work... >> Otherwise, the behaviour of maps, slices and funcs cannot be fully >> explained. >> >> On Sunday, July 3, 2016 at 7:25:31 AM UTC+2, as@gmail.com wrote: >>> >>> Go does not have reference types. As far as I know, the word was >>> purposefully removed from the spec to remove the ambiguity surrounding the >>> word. >>> >>> https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA >> >> >> >> @Martin >> >> As I've mentioned earlier, one ought to be careful about false friends >> from other languages. >> I am not sure I understand what you mean by: >> >> if the name field is changed after the call >> >> >> -- 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] Re: Relaxing rules on slice comparison: would it make sense?
Oh, maybe you mistook reference type for the notion of reference.
On Sunday, July 3, 2016 at 9:49:34 AM UTC+2, Martin Geisler wrote:
>
> Hi Chad,
>
> On Sat, Jul 2, 2016 at 10:43 AM, Chad >
> wrote:
> >
> > On Saturday, July 2, 2016 at 10:23:04 AM UTC+2, Martin Geisler wrote:
> >>
> >> On Fri, Jul 1, 2016 at 4:01 PM, Chad wrote:
> >>>
> >>> On Friday, July 1, 2016 at 3:44:10 PM UTC+2, Martin Geisler wrote:
> >>>> I keep seeing references (hah!) to this concept of a "reference type"
> >>>> :-) However, I just tried searching the language spec and Effective
> Go
> >>>> and there doesn't seem to be such a concept defined in those
> >>>> documents.
> >>>
> >>> I think it should. It is mentioned here however
> >>> https://blog.golang.org/go-maps-in-action
> >>
> >> You're right, that article calls maps, slices and pointers "reference
> >> types".
> >>
> >> I feel that is a little unfortunate since it muddles the picture and
> >> makes the implementation more obscure. I would have been happy to have
> >> been told right from the start that a slice is a small struct, small
> >> enough that you can pass it by value instead of with a pointer. That
> >> allows me to build a mental model in terms of other Go constructs.
> >
> >
> > A struct is considered a reference type if at least one of the field
> > *points* to another object. (i.e. holds a reference to another object).
> > https://en.wikipedia.org/wiki/Reference_type
>
> That is not how I've seen the word "reference type" used and I don't
> think that's what the Wikipedia article tries to say. As I read it, it
> says that a language like C++ has some types that are value types
> (int, bool, structs, classes) and some types that are reference types
> (&int, &bool).
>
> As far as I know, reference types only show up in function and method
> signatures in C++. It specifies that the argument should be passed by
> reference instead of being copied like normal -- the compiler will
> typically handle this by changing the &int parameter to a *int (int
> pointer) parameter, insert & at the call site and * inside the
> function. So the reference type gives you almost the same as a
> pointer, but without the explicit dereferencing.
>
> Other languages like Java and Python have reference types too: in
> Java, all object instances are reference types. So when you pass an
> object to a method, you pass a reference and modifications done in the
> method are visible after the call.
>
> I believe C# allows you to specify if you want a class to be a
> reference type or a value type. The Wikipedia article says you use
> "struct" for value types and "class" for reference types. This matches
> how "struct" gives you a value type in Go.
>
> The mail from as.utf8 points to this discussion (thanks!):
>
> https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA
>
> which points to this issue:
>
> https://github.com/golang/go/issues/5083
>
> They make it pretty clear that people have been trying to remove the
> use of "reference type".
>
> > It's clearer. "small struct" would not be explicit enough nor true.
> > I think that slices require typically more documentation effort to
> clarify
> > what they are. Then, the issue of comparability will be obvious.
> >
> > There are user-defined reference types too.
> >
> > type Foo struct{
> >name string
> >data *[192]byte
> > }
> >
> > That would be a reference type. This one is comparable.
>
> I don't think that's a reference type in the usual sense of the word.
> The basic test for me is what happens when you pass a Foo to a
> function:
>
> func ChangeTheFoo(f Foo) {
> f.name = "changed"
> }
>
> if the name field is changed after the call, then Foo is indeed a
> reference type. However, it won't be changed in Go since the Foo
> struct is copied when the function is called and this is why I say
> that Foo is not a reference type. That is true of all structs in Go.
>
> --
> Martin Geisler
>
--
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] Re: Relaxing rules on slice comparison: would it make sense?
Rob and Robert actually wrote that this area of the spec needs more work... Otherwise, the behaviour of maps, slices and funcs cannot be fully explained. On Sunday, July 3, 2016 at 7:25:31 AM UTC+2, as@gmail.com wrote: > > Go does not have reference types. As far as I know, the word was > purposefully removed from the spec to remove the ambiguity surrounding the > word. > > https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA @Martin As I've mentioned earlier, one ought to be careful about false friends from other languages. I am not sure I understand what you mean by: if the name field is changed after the call -- 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] Re: Relaxing rules on slice comparison: would it make sense?
You can do that, but for correctness, I am arguing that it's not what you should expect for slices by default. On Sunday, July 3, 2016 at 3:37:15 AM UTC+2, Florin Pățan wrote: > > I would also expect to compare values not memory locations, generally > that's what I'm interested in comparing. > > I never had the need to compare equality for memory locations of anything > in Go (especially not for slices / maps oe their elements). > -- 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: A proposal for generic in go
What's generic programming? An implementation of overloading for datastructures and function/methods. The compiler is left in charge of going through the code and specifying which types should actually be used. Go restricts the overloading of function/methods. So we are left with the specification of new datastructures. To be fair, unless in very specific cases, datastructures specifically created to be safe for concurrent use are not too useful. The reason being that their content is not deterministic. It is tied to the scheduler. Write-only datastructures are probably the only interesting case that is interesting. I mean, for instance, concurrent writes to a map while no reads occurs. The only interesting case otherwise would be the concurrent reading/writing of an append only datastructure, but that would probably be a very specific tuning for speed. So the only very interesting datastructures that would be remaining are datastructures that are fast to read from concurrently (maps are quite fast in Go) Or fast to write to concurrently. I wonder which kind of datastructures people may want to write. But I have the impression that what people truly want is being able to overload functions. That's complicated. Multiple dispatch may be slow, perhaps unresolvable.. there are issues on that side. Besides introducing unwarranted implicitness. The appeal of generics is probably a false appeal. On Wednesday, June 15, 2016 at 3:04:05 AM UTC+2, xingtao zhao wrote: > > Here is my proposal for generic in go: > https://docs.google.com/document/d/1nO7D15c2B3eq2kF62C0yUs_UgpkyPL2zHhMAmlq1l98/edit?usp=sharing > > Many parts has not been finished, and just initial thoughts. In the > proposal, I want to keep back compatibility. And I try to add the > orthogonal feature only and keep the language still simple enough. > > Please add your comments on it. Hope it is useful and could inspire some > new features in go 2.0 > > Thanks! > -- 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] Re: Relaxing rules on slice comparison: would it make sense?
On Saturday, July 2, 2016 at 6:19:56 AM UTC+2, Matt Harden wrote: > > Conceptually, the value of a string is the sequence of bytes it contains, > just like an array of bytes. It doesn't matter that the implementation of > strings looks more like a slice internally. On the other hand the value of > a slice is a reference to (part of) an underlying array, together with a > length. In all cases == should compare values. > It does(*). But for a slice, it "also" compares the location of those values. That's the difference between a slice and an array. (*) : well, or rather, it probably should . > I agree that it would be confusing to make == work for slices, because > many people, myself included would intuitively want that to compare the > contents of the slice (values from the underlying array) rather than the > value of the slice itself which is essentially 3 pointers. > > That's just a matter of realizing what a slice really is. I think It's more of a documentation issue to clear up the misconception. That should not impede the language from being improved. > One nice feature of the current gc compiler AIUI is that it will avoid a > copy in some circumstances when you convert a byte slice to a string and > immediately use it as a map key. This helps with using []byte values to > index into maps, but doesn't help when the []byte is part of a larger > structure you want to use as a key. > > On Fri, Jul 1, 2016 at 7:05 AM Chad > > wrote: > >> >> >> On Friday, July 1, 2016 at 4:01:54 PM UTC+2, Chad wrote: >> >>> >>> >>> On Friday, July 1, 2016 at 3:44:10 PM UTC+2, Martin Geisler wrote: >>>> >>>> On Fri, Jul 1, 2016 at 12:52 PM, Chad wrote: >>>> > However, that it's a valid point you raise (re strings) >>>> > But that's exactly the reason for which, someone would probably ask >>>> whether >>>> > a string is a reference type or a value type. >>>> > >>>> > This could probably made clearer in the documentation. >>>> >>>> I keep seeing references (hah!) to this concept of a "reference type" >>>> :-) However, I just tried searching the language spec and Effective Go >>>> and there doesn't seem to be such a concept defined in those >>>> documents. >>> >>> >>> I think it should. It is mentioned here however >>> https://blog.golang.org/go-maps-in-action >>> >>> Without that, one of the first instinct of beginning programmers is >>> often to create pointers to slices ** *or maps *** >>> >> >> (And I should know, I did that :) >> >> >>> >>>> -- >> 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] Re: Relaxing rules on slice comparison: would it make sense?
On Saturday, July 2, 2016 at 10:23:04 AM UTC+2, Martin Geisler wrote:
>
> On Fri, Jul 1, 2016 at 4:01 PM, Chad >
> wrote:
> >
> >
> > On Friday, July 1, 2016 at 3:44:10 PM UTC+2, Martin Geisler wrote:
> >>
> >> On Fri, Jul 1, 2016 at 12:52 PM, Chad wrote:
> >> > However, that it's a valid point you raise (re strings)
> >> > But that's exactly the reason for which, someone would probably ask
> >> > whether
> >> > a string is a reference type or a value type.
> >> >
> >> > This could probably made clearer in the documentation.
> >>
> >> I keep seeing references (hah!) to this concept of a "reference type"
> >> :-) However, I just tried searching the language spec and Effective Go
> >> and there doesn't seem to be such a concept defined in those
> >> documents.
> >
> >
> > I think it should. It is mentioned here however
> > https://blog.golang.org/go-maps-in-action
>
> You're right, that article calls maps, slices and pointers "reference
> types".
>
> I feel that is a little unfortunate since it muddles the picture and
> makes the implementation more obscure. I would have been happy to have
> been told right from the start that a slice is a small struct, small
> enough that you can pass it by value instead of with a pointer. That
> allows me to build a mental model in terms of other Go constructs.
>
A struct is considered a reference type if at least one of the field
*points* to another object. (i.e. holds a reference to another object).
https://en.wikipedia.org/wiki/Reference_type
It's clearer. "small struct" would not be explicit enough nor true.
I think that slices require typically more documentation effort to clarify
what they are. Then, the issue of comparability will be obvious.
There are user-defined reference types too.
type Foo struct{
name string
data *[192]byte
}
That would be a reference type. This one is comparable.
>
> It might very well be that a slice isn't implemented *exactly* like a
> struct, but if the mental picture of a struct explains the behavior
> and performance characteristics, then it doesn't matter if the
> compiler somehow cheats here and there when implementing the type.
>
> > Without that, one of the first instinct of beginning programmers is
> often to
> > create pointers to slices.
> > I feel that, more clarifications about this area of the language would
> help
> > a lot instead.
> >
> > This is also a terminology of PLT that exists in other languages but as
> > usual, one has to be careful about the implementation false friends.
>
> I agree, "reference type" is a widely used term. I think I prefer to
> use it only for pointer types such as *int, *byte and so on.
> Everything else would be value types, including string, map[int]int,
> []float and other special builtin types.
>
> When talking about equality, the language defines some of these types
> as comparable, with per-type rules for how == is implemented. Relaxing
> the rules to allow comparing slices (by pair-wise comparison of the
> values in the slices) seems like a natural thing to do for me. It
> would make slice comparison work like string comparison works
> currently. So the rule for comparison would not even be new or strange
> -- just a natural extension of what is already there.
>
> You could probably also make slices (and arrays) ordered, provides the
> elements themselves are ordered. That would work the same way strings
> work today: lexicographic ordering based on the elements.
>
> --
> Martin Geisler
>
--
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] Re: Relaxing rules on slice comparison: would it make sense?
On Friday, July 1, 2016 at 4:01:54 PM UTC+2, Chad wrote: > > > > On Friday, July 1, 2016 at 3:44:10 PM UTC+2, Martin Geisler wrote: >> >> On Fri, Jul 1, 2016 at 12:52 PM, Chad wrote: >> > However, that it's a valid point you raise (re strings) >> > But that's exactly the reason for which, someone would probably ask >> whether >> > a string is a reference type or a value type. >> > >> > This could probably made clearer in the documentation. >> >> I keep seeing references (hah!) to this concept of a "reference type" >> :-) However, I just tried searching the language spec and Effective Go >> and there doesn't seem to be such a concept defined in those >> documents. > > > I think it should. It is mentioned here however > https://blog.golang.org/go-maps-in-action > > Without that, one of the first instinct of beginning programmers is often > to create pointers to slices ** *or maps *** > (And I should know, I did that :) > >> -- 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] Re: Relaxing rules on slice comparison: would it make sense?
On Friday, July 1, 2016 at 3:44:10 PM UTC+2, Martin Geisler wrote: > > On Fri, Jul 1, 2016 at 12:52 PM, Chad > > wrote: > > However, that it's a valid point you raise (re strings) > > But that's exactly the reason for which, someone would probably ask > whether > > a string is a reference type or a value type. > > > > This could probably made clearer in the documentation. > > I keep seeing references (hah!) to this concept of a "reference type" > :-) However, I just tried searching the language spec and Effective Go > and there doesn't seem to be such a concept defined in those > documents. I think it should. It is mentioned here however https://blog.golang.org/go-maps-in-action Without that, one of the first instinct of beginning programmers is often to create pointers to slices. I feel that, more clarifications about this area of the language would help a lot instead. This is also a terminology of PLT that exists in other languages but as usual, one has to be careful about the implementation false friends. > Effective Go talks about slices and maps having > "references" to some underlying data, but I don't think it says that > maps and slices themselves are "reference types". > > So my understanding is that there is no such concept in Go. Instead > there are structs and pointers -- maps and slices are builtin types, > implemented as small structs that points to larger pieces of data. > When you pass either to a function, you end up copying the struct -- > the normal value semantic we all know so well. Copying the struct is > fine since they're small: a slice is a pointer and two ints, I'm > unsure how a map looks like but I hope it's similarly sized. > > I'm very new to Go, so please let me know if I'm missing anything? > > -- > Martin Geisler > -- 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] Re: Relaxing rules on slice comparison: would it make sense?
Yes. You're absolutely right.That's due to the current implementation of
strings.
Maybe they should be implemented as a struct with an unexported array of
byte
That would just work.
Having the string kind with the same structure as a slice is the problem
here. strings should probably be pure values.
In any case, that's still an issue of defining what a value type and a
reference type are.
The implementation is a guide but it should not influence the spec so much
as well.
slices are reference types and the comparison behaviour should be obvious:
it's determining whether they reference the same thing.
strings are value types and likewise, the comparison behaviour is obvious.
On Friday, July 1, 2016 at 3:35:01 PM UTC+2, Martin Geisler wrote:
>
> On Fri, Jul 1, 2016 at 12:48 PM, Chad >
> wrote:
> > On Friday, July 1, 2016 at 12:11:43 PM UTC+2, Martin Geisler wrote:
> >>
> >> On Fri, Jul 1, 2016 at 3:15 AM, Chad wrote:
> >> > No, it's actually fine. You are comparing values.
> >> >
> >> > A slice being a struct under the hood, for slices you would compare
> the
> >> > structs (slice headers)
> >>
> >> Yes, when you remember that a slice is a just a small struct with a
> >> pointer and some bookkeeping information (length, capacity), then you
> >> can compare two slices easily. So with
> >>
> >> a := []int{10, 20, 30}
> >> b := a[:]
> >>
> >> then a == b would be fast: simply compare the pointers and the
> >> bookkeeping information. Direct value equality between the structs
> >> gives you the expected and correct answer.
> >>
> >> But what about
> >>
> >> []int{10, 20} == []int{10, 20}
> >>
> >> where the two slices refer to different underlying arrays? I think you
> >> argue that this comparison should be false?
> >
> >
> > Yes. And it is. A slice is not an array. Or an open-ended array.
>
> Right, a slice is just view into an array :-)
>
> I was hinting at the (lack of) symmetry with how strings work.
>
> Two strings that share no underlying memory can compare equal, so I
> think it would be reasonable if equality between slices followed the
> same principle. Put differently, strings are "magic" and don't follow
> normal rules for comparison, in particular, they don't use direct
> value comparison. Here I'm assuming that
>
> https://golang.org/pkg/reflect/#StringHeader
>
> shows us how strings are implemented: a small struct with a pointer
> and a length. If string comparison were to use value semantics, a and
> b could not compare equal in this little example
>
> a := "hello world"
> b := make([]byte, len(a))
> os.Stdin.Read(b)
>
> since the pointer in a would differ from the pointer in b. Yet a == b
> is true when you enter "hello world" :-) So we see the magic slip
> through the cracks...
>
> Given that, one could argue that it would be consistent to have
> []int{1} == []int{1} be true -- it's just yet another exception to the
> rule that things are compared by value. It's not super pretty, though,
> but I my opinion the illusion of prettyness has already been broken
> with how some builtin types get special treatment here and there.
>
> --
> Martin Geisler
>
--
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] Re: Relaxing rules on slice comparison: would it make sense?
However, that it's a valid point you raise (re strings)
But that's exactly the reason for which, someone would probably ask whether
a string is a reference type or a value type.
This could probably made clearer in the documentation.
On Friday, July 1, 2016 at 12:48:28 PM UTC+2, Chad wrote:
>
> On Friday, July 1, 2016 at 12:11:43 PM UTC+2, Martin Geisler wrote:
>>
>> On Fri, Jul 1, 2016 at 3:15 AM, Chad wrote:
>> > No, it's actually fine. You are comparing values.
>> >
>> > A slice being a struct under the hood, for slices you would compare the
>> > structs (slice headers)
>>
>> Yes, when you remember that a slice is a just a small struct with a
>> pointer and some bookkeeping information (length, capacity), then you
>> can compare two slices easily. So with
>>
>> a := []int{10, 20, 30}
>> b := a[:]
>>
>> then a == b would be fast: simply compare the pointers and the
>> bookkeeping information. Direct value equality between the structs
>> gives you the expected and correct answer.
>>
>> But what about
>>
>> []int{10, 20} == []int{10, 20}
>>
>> where the two slices refer to different underlying arrays? I think you
>> argue that this comparison should be false?
>>
>
> Yes. And it is. A slice is not an array. Or an open-ended array.
>
> I would hope that slices from different underlying arrays could be
>> compared for equality based on their values, just like strings can.
>> Two strings (that are not slices from the same original string) can be
>> compared for equality just fine. I hope Go takes the shortcut when the
>> strings refer to the same memory and otherwise does the slower
>> per-byte comparison. The same could perhaps apply to slices in
>> general.
>>
>> strings are immutable. They are more akin to an array of bytes than a
> slice of bytes.
>
>> --
>> Martin Geisler
>>
>
--
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] Re: Relaxing rules on slice comparison: would it make sense?
On Friday, July 1, 2016 at 12:11:43 PM UTC+2, Martin Geisler wrote:
>
> On Fri, Jul 1, 2016 at 3:15 AM, Chad >
> wrote:
> > No, it's actually fine. You are comparing values.
> >
> > A slice being a struct under the hood, for slices you would compare the
> > structs (slice headers)
>
> Yes, when you remember that a slice is a just a small struct with a
> pointer and some bookkeeping information (length, capacity), then you
> can compare two slices easily. So with
>
> a := []int{10, 20, 30}
> b := a[:]
>
> then a == b would be fast: simply compare the pointers and the
> bookkeeping information. Direct value equality between the structs
> gives you the expected and correct answer.
>
> But what about
>
> []int{10, 20} == []int{10, 20}
>
> where the two slices refer to different underlying arrays? I think you
> argue that this comparison should be false?
>
Yes. And it is. A slice is not an array. Or an open-ended array.
I would hope that slices from different underlying arrays could be
> compared for equality based on their values, just like strings can.
> Two strings (that are not slices from the same original string) can be
> compared for equality just fine. I hope Go takes the shortcut when the
> strings refer to the same memory and otherwise does the slower
> per-byte comparison. The same could perhaps apply to slices in
> general.
>
> strings are immutable. They are more akin to an array of bytes than a
slice of bytes.
> --
> Martin Geisler
>
--
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] Re: Relaxing rules on slice comparison: would it make sense?
> > You don't have to, you can use a pointer indirection instead. > > I have explained why it was not sufficient upstream. I don't expect people to create two version of their types, one being for mere inclusion into maps. -- 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] Re: Relaxing rules on slice comparison: would it make sense?
Again, if you really understand the datastructure and what it represents, the behaviour is really not surprising. There is no value "abstraction". And currently, a comparison panics. Any interface comparison may panic if the underlying type is a slice. I don't see a good reason for that. That's why I have mentioned "relaxing". I also don't see why someone would need to import unsafe for this, leaving alone the fact that some hosting solutions may not allow the import of this package. On Friday, July 1, 2016 at 3:39:12 AM UTC+2, kortschak wrote: > > On Thu, 2016-06-30 at 18:15 -0700, Chad wrote: > > No, it's actually fine. You are comparing values. > > The issue is that, yes while everything is a value, the value > abstraction is tenuous in this context. The result of this tenuous > abstraction is that there would be surprising behaviours (already > outlined by others). > > > A slice being a struct under the hood, for slices you would compare > > the structs (slice headers) > > > > For an interface, you compare two pointers (in the current > > implementation) > > > > etc. > > > > "==" is just value comparison everywhere. > > > > Everything is a value. > > Some of the values are not specified in the language specification. > Making this equality comparison possible for all types would require > that these be specified, locking in the current implementation. > > This would be to get behaviour that is already available either by > indirection or import of unsafe. > > -- 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] Re: Relaxing rules on slice comparison: would it make sense?
No, it's actually fine. You are comparing values. A slice being a struct under the hood, for slices you would compare the structs (slice headers) For an interface, you compare two pointers (in the current implementation) etc. "==" is just value comparison everywhere. Everything is a value. On Friday, July 1, 2016 at 2:01:11 AM UTC+2, kortschak wrote: > > This position precludes the following use of the equality operator for > scalar values: > > a := 1 > b := 1 > > a == b would be false under the approach below since a and b are not the > same set of bits. > > I think most people would find this a little surprising. > > On Thu, 2016-06-30 at 09:24 -0700, Chad wrote: > > It's a view in another array. > > Why should they be equal? Unless the second slice is constructed by > > subslicing the other as such `[:]`, the slices *are* different. > > > > If I were to access one of the slice backing array and mutate it, I > > wouldn't expect the slices to be equal anymore. > > > > The argument that it would be surprising is perhaps flawed because it > stems > > from a misconception. > > A slice is a dynamic view. For two slices to be equal it makes sense to > be > > looking at the same thing at all time. > > > > Taken mathematically, if we describe an indirection as a mathematical > > function, a slice is such a function. Two functions are equals if they > are > > equals everywhere they are defined. A slice is equal to another slice if > > the backign arrays always have the same values, whatever mutation occurs > on > > any of them. > > > > Comparing the snapshot view of a slice would then different. The > behaviour > > seems consistent to me. > > > -- 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] Re: Relaxing rules on slice comparison: would it make sense?
I'd rather people were given a correct simple explanation rather than
foregoing any explanation because it may appear complex at first sight.
Especially since it alters how maps can be used, later on. (the hashing
algorithm relies on comparability).
On Thursday, June 30, 2016 at 10:32:58 PM UTC+2, Jakob Borg wrote:
>
> 2016-06-30 22:23 GMT+02:00 Chad >:
> >> Your proposition merely moves the semantical constraint to another
> >> place: as Ian pointed out, if we define equality for slices to be
> >> something resembling pointer equality suddenly []byte{1, 2} is not
> equal
> >> to []byte{1, 2}.
> >
> >
> > They are not since creating a slice allocate a different underlying
> array
> > each time. They are not views on the same array.
> > It is merely incidental that on the example that is given, the two
> arrays
> > have the same first and second elements.
>
> This may seem entirely obvious to you, but explaining to a newcomer why
>
> fmt.Println(1 == 1) // => true
> fmt.Println("2" == "2") // => true
> fmt.Println([...]int{1, 2} == [...]int{1, 2}) // => true
> fmt.Println([]int{1, 2} == []int{1, 2}) // => false
is not something I feel would make the language better.
> //jb
>
One way to go about this would be to put more emphasis on the concept of
reference type in the documentation and introduce this behaviour as the
main divergence from pure value types. But that wouldn't be the most
complex thing to learn.
--
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] Re: Relaxing rules on slice comparison: would it make sense?
> Your proposition merely moves the semantical constraint to another
> place: as Ian pointed out, if we define equality for slices to be
> something resembling pointer equality suddenly []byte{1, 2} is not equal
> to []byte{1, 2}.
>
They are not since creating a slice allocate a different underlying array
each time. They are not views on the same array.
It is merely incidental that on the example that is given, the two arrays
have the same first and second elements.
As discussed above, there is no semantic problem that has really been
pointed out.
It's a mere comparison of the slice header, a mere value comparison. Just
as what would be done for any other type.
> The approach I have proposed (a custom "keying" function) is actually
> what "every other language" does, just more explicit. Say, .NET's
> collections rely on their members implementing various interfaces such
> as IHashCodeProvider. My "keying" function merely provides a mapping
> from values which cannot be used as keys directly to some other values
> which can -- using your own rules. Since your rules would be codified
> explicitly, there would be no cognitive burden for the next programmer
> reading your code.
>
> > And it's on any type that has one or more fields of type slice/map/
> > or func.
> >
> > The alternative is to implement one's own associative array
> > datastructure with one's own hashing algorithm etc but that's still
> > going to be clunky since it will be implementation dependent and will
> > rely on the use of unsafe.
>
> I propose putting such "hashing algorithm" outside of the datastructure.
>
> Basically what I propose is replacing
>
> collection(K → V)
>
> with
>
> collection(K' → V)
>
> where K' is derived from K using your own function: K' = fn(K).
>
> The collection stays unmodified, you just transform its keys.
>
There is no real need for another indirection in Go. It's really
straightforward.
--
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] Re: Relaxing rules on slice comparison: would it make sense?
In fact I'd rather deal with the general issue by relaxing some rules, if
it's something that is deemed worthy of being dealt with.
Basically if you have a map[interface{}]interface{} because you have a
mixed bag of value that you fill at runtime, you cannot actually use any
type you want as the key.
Semantically, there is an additional constraint that I don't believe should
exist.
And it's on any type that has one or more fields of type slice/map/ or func.
The alternative is to implement one's own associative array datastructure
with one's own hashing algorithm etc but that's still going to be clunky
since it will be implementation dependent and will rely on the use of
unsafe.
On Thursday, June 30, 2016 at 8:21:32 PM UTC+2, Konstantin Khomoutov wrote:
>
> On Thu, 30 Jun 2016 09:55:30 -0700 (PDT)
> Chad > wrote:
>
> > I understand the worry but the more I think about it, the less I
> > think it would end up being a real issue.
> >
> > Taking the example of maps... two different maps that have not the
> > same location in memory are never equal, especially since modifying
> > one does not modify the other. It's easily explained.
> >
> > For slices, explaining that it's a view of an array, and views of
> > different arrays are not considered equals, it would also be easily
> > explained to a beginning programmer.
> >
> > Well it's merely food for thoughts. (but it would solve later issues
> > in the usability of maps)
>
> I think you can get away using helper functions.
>
> Say, having
>
> type SliceKey struct {
> Ptr unitptr
> }
>
> func Key(s []byte) SliceKey
> {
> ...
> }
>
> which would calculate whatever suits your needs from its parameter,
> you could use it to actually turn your slices and maps into proper keys.
>
> Such a function can just use package unsafe to crack the slice header
> value in whatever way it wishes (as in the piece of advice from Daniel
> Skinner earlier in this thread).
>
> Working with a map would then look something like
>
> m := make(map[SliceKey]int)
>
> b := []byte{1, 2, 3}
>
> m[Key(b)] = 42
>
> v := m[Key(b)]
>
--
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] Re: Relaxing rules on slice comparison: would it make sense?
I understand the worry but the more I think about it, the less I think it
would end up being a real issue.
Taking the example of maps... two different maps that have not the same
location in memory are never equal, especially since modifying one does not
modify the other. It's easily explained.
For slices, explaining that it's a view of an array, and views of different
arrays are not considered equals, it would also be easily explained to a
beginning programmer.
Well it's merely food for thoughts. (but it would solve later issues in the
usability of maps)
On Thursday, June 30, 2016 at 6:28:47 PM UTC+2, Ian Lance Taylor wrote:
>
> On Thu, Jun 30, 2016 at 9:24 AM, Chad >
> wrote:
> > It's a view in another array.
> > Why should they be equal? Unless the second slice is constructed by
> > subslicing the other as such `[:]`, the slices are different.
> >
> > If I were to access one of the slice backing array and mutate it, I
> wouldn't
> > expect the slices to be equal anymore.
> >
> > The argument that it would be surprising is perhaps flawed because it
> stems
> > from a misconception.
> > A slice is a dynamic view. For two slices to be equal it makes sense to
> be
> > looking at the same thing at all time.
> >
> > Taken mathematically, if we describe an indirection as a mathematical
> > function, a slice is such a function. Two functions are equals if they
> are
> > equals everywhere they are defined. A slice is equal to another slice if
> the
> > backign arrays always have the same values, whatever mutation occurs on
> any
> > of them.
> >
> > Comparing the snapshot view of a slice would then different. The
> behaviour
> > seems consistent to me.
>
> This discussion is a good example of why the language does not define
> the behavior. There are solid arguments on both sides.
>
> Ian
>
>
> > On Thursday, June 30, 2016 at 4:54:59 PM UTC+2, Paul Borman wrote:
> >>
> >> It would be very surprising to people to use a slice as a key to map,
> say
> >> []int{1,2} and then find that using another []int{1,2} does not find
> that
> >> entry. While I think it would be nice to have == on slices, I must
> agree
> >> with Ian and authors that it is better left unsaid.
> >>
> >> -Paul
> >>
> >> On Thu, Jun 30, 2016 at 1:09 AM, Chad wrote:
> >>>
> >>>
> >>>
> >>> On Thursday, June 30, 2016 at 8:32:58 AM UTC+2, Viktor Kojouharov
> wrote:
> >>>>
> >>>> This would probably introduce unnecessary confusion. People are used
> to
> >>>> the equality operator comparing values in go, as opposed to
> references. It's
> >>>> much better if the slices finally support the equality operator, even
> though
> >>>> the comparison speed will depend on the number of items in the
> slices.
> >>>>>
> >>>>>
> >>> Well, in fact, everything is a value in Go. It's just that the
> internal
> >>> structure of the standard reference types are not exposed.
> >>> The behaviour should not be very different from the comparison between
> >>> user defined structs where one or more fields are pointers.
> >>>
> >>> It also makes sense to say that two slices are equal iff they
> represent
> >>> the exact same views of the exact same underlying array.
> >>>
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> Groups
> >>> "golang-nuts" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send
> an
> >>> email to golang-nuts...@googlegroups.com.
> >>> For more options, visit https://groups.google.com/d/optout.
> >>
> >>
> > --
> > You received this message because you are subscribed to the Google
> Groups
> > "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an
> > email to golang-nuts...@googlegroups.com .
> > For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?
It's a view in another array.
Why should they be equal? Unless the second slice is constructed by
subslicing the other as such `[:]`, the slices *are* different.
If I were to access one of the slice backing array and mutate it, I
wouldn't expect the slices to be equal anymore.
The argument that it would be surprising is perhaps flawed because it stems
from a misconception.
A slice is a dynamic view. For two slices to be equal it makes sense to be
looking at the same thing at all time.
Taken mathematically, if we describe an indirection as a mathematical
function, a slice is such a function. Two functions are equals if they are
equals everywhere they are defined. A slice is equal to another slice if
the backign arrays always have the same values, whatever mutation occurs on
any of them.
Comparing the snapshot view of a slice would then different. The behaviour
seems consistent to me.
On Thursday, June 30, 2016 at 4:54:59 PM UTC+2, Paul Borman wrote:
>
> It would be very surprising to people to use a slice as a key to map, say
> []int{1,2} and then find that using another []int{1,2} does not find that
> entry. While I think it would be nice to have == on slices, I must agree
> with Ian and authors that it is better left unsaid.
>
> -Paul
>
> On Thu, Jun 30, 2016 at 1:09 AM, Chad >
> wrote:
>
>>
>>
>> On Thursday, June 30, 2016 at 8:32:58 AM UTC+2, Viktor Kojouharov wrote:
>>>
>>> This would probably introduce unnecessary confusion. People are used to
>>> the equality operator comparing values in go, as opposed to references.
>>> It's much better if the slices finally support the equality operator, even
>>> though the comparison speed will depend on the number of items in the
>>> slices.
>>>
>>>>
>>>> Well, in fact, everything is a value in Go. It's just that the
>> internal structure of the standard reference types are not exposed.
>> The behaviour should not be very different from the comparison between
>> user defined structs where one or more fields are pointers.
>>
>> It also makes sense to say that two slices are equal iff they represent
>> the exact same views of the exact same underlying array.
>>
>>
>> --
>> 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] Re: Relaxing rules on slice comparison: would it make sense?
On Thursday, June 30, 2016 at 8:32:58 AM UTC+2, Viktor Kojouharov wrote: > > This would probably introduce unnecessary confusion. People are used to > the equality operator comparing values in go, as opposed to references. > It's much better if the slices finally support the equality operator, even > though the comparison speed will depend on the number of items in the > slices. > >> >> Well, in fact, everything is a value in Go. It's just that the internal structure of the standard reference types are not exposed. The behaviour should not be very different from the comparison between user defined structs where one or more fields are pointers. It also makes sense to say that two slices are equal iff they represent the exact same views of the exact same underlying array. -- 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] Relaxing rules on slice comparison: would it make sense?
> > The problem is that different programs need different things for slice > equality. Some want pointer equality as you suggest. Some want > element comparisons, as is done for array equality. Without an > obvious semantics for the operation, the language omits it entirely. > That's true. However, the flipside of the coin is that perfectly marshallable objects cannot be used as map keys because at least one field is a slice, map or function. That restricts the usage of maps sometimes unnecessarily. If the equality operator were to have the same semantic everywhere (mere value comparison, whether for a pointer, map/slice/func or an array), it would solve the issue. The spec would not even have to rely on the internal structure of a slice, map or function. -- 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] Re: Relaxing rules on slice comparison: would it make sense?
So that it becomes valid map inputs. What should be hashed would be the slice/map/ref type value. On Wednesday, June 29, 2016 at 8:38:03 PM UTC+2, Konstantin Khomoutov wrote: > > On Wed, 29 Jun 2016 11:20:46 -0700 (PDT) > Chad > wrote: > > > And actually the same for any other similar types such as maps... > > > > > > On Wednesday, June 29, 2016 at 8:19:45 PM UTC+2, Chad wrote: > > > > > > Just been thinking that since a slice is a "reference" type, why > > > not allow slice equality? > > > Of course the number of cases where two slices are equal would be > > > quite low, irrelevant of whether the view they have on their > > > respective arrays is the same. > > > > > > I'm thinking about something analogous to comparing pointer values. > > > No notion of deep equality as can be done via reflect. > > What would be the use cases? > -- 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: Relaxing rules on slice comparison: would it make sense?
And actually the same for any other similar types such as maps... On Wednesday, June 29, 2016 at 8:19:45 PM UTC+2, Chad wrote: > > Just been thinking that since a slice is a "reference" type, why not allow > slice equality? > Of course the number of cases where two slices are equal would be quite > low, irrelevant of whether the view they have on their respective arrays is > the same. > > I'm thinking about something analogous to comparing pointer values. No > notion of deep equality as can be done via reflect. > > > > > -- 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] Relaxing rules on slice comparison: would it make sense?
Just been thinking that since a slice is a "reference" type, why not allow slice equality? Of course the number of cases where two slices are equal would be quite low, irrelevant of whether the view they have on their respective arrays is the same. I'm thinking about something analogous to comparing pointer values. No notion of deep equality as can be done via reflect. -- 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: Best practice when putting large amounts of functionality behind an interface
What does the interface look like currently? On Monday, June 27, 2016 at 10:54:31 PM UTC+2, Tyler Compton wrote: > > Right now, I have a web server with an interface that defines methods for > every kind of database read/write operation my application has. > Any example ? > Unsurprisingly, it's pretty large for a Go interface at around 30 methods. > I originally did this because I wanted to be able to support multiple > implementations of my database layer, but now it's only so that I can mock > out this functionality for testing, which is still important to me. > > This works fine, but it doesn't /feel/ right, whatever that means. As the > proverb goes, "the bigger the interface, the weaker the abstraction." To be > fair, I'm not really going for a lot of abstraction here. The only objects > that should implement this interface would be geared very heavily towards > my needs. Maybe that's where I went wrong. > > Is there a more idiomatic way I could be doing this? > Interfaces are composable so you could probably make a slight refactor where you assemble methods by usage. It may help keep things clearer. -- 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: Discussion on "Vendoring edge case, critical problem"
But if you vendor, you don't really need type equality do you? Maybe it's a design flaw when types or interfaces with unexported methods from the vendored pkg are visible to the end user of the vendoring pkg. On Sunday, June 19, 2016 at 10:52:34 PM UTC+2, Dave Cheney wrote: > > If you mean forking their dependencies and rewiring their import paths, > that is a possibility. But it leaves consumers of those packages in the > same position as the thread the OP referenced because the same code is now > known by two distinct import paths breaking type equality. -- 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.
