Hello golang-dev@googlegroups.com (cc: golang-dev@googlegroups.com, rsc@golang.org), I'd like you to review this change to https://code.google.com/p/go
11 years, 11 months ago
(2013-07-25 19:47:08 UTC)
#1
All done except src/pkg/runtime/mfinal_test.go:29. What do you propose? https://codereview.appspot.com/11858043/diff/5001/src/pkg/runtime/malloc.goc File src/pkg/runtime/malloc.goc (right): https://codereview.appspot.com/11858043/diff/5001/src/pkg/runtime/malloc.goc#newcode851 src/pkg/runtime/malloc.goc:851: uintptr ...
11 years, 11 months ago
(2013-07-26 23:31:24 UTC)
#3
On 2013/07/27 10:06:35, dvyukov wrote: > On Sat, Jul 27, 2013 at 3:31 AM, <mailto:pieter@binky.org.uk> ...
11 years, 11 months ago
(2013-07-27 10:16:48 UTC)
#6
On 2013/07/27 10:06:35, dvyukov wrote:
> On Sat, Jul 27, 2013 at 3:31 AM, <mailto:pieter@binky.org.uk> wrote:
> > All done except src/pkg/runtime/mfinal_test.go:29.
> >
> > What do you propose?
>
>
> The test works for me on darwin/amd64 with t.Skipped() commented out.
> Does it fail for you now?
Indeed, it does work now. Magic.
Anything else?
On 2013/07/27 10:16:48, peted wrote: > On 2013/07/27 10:06:35, dvyukov wrote: > > On Sat, ...
11 years, 11 months ago
(2013-07-27 10:18:52 UTC)
#7
On 2013/07/27 10:16:48, peted wrote:
> On 2013/07/27 10:06:35, dvyukov wrote:
> > On Sat, Jul 27, 2013 at 3:31 AM, <mailto:pieter@binky.org.uk> wrote:
> > > All done except src/pkg/runtime/mfinal_test.go:29.
> > >
> > > What do you propose?
> >
> >
> > The test works for me on darwin/amd64 with t.Skipped() commented out.
> > Does it fail for you now?
>
> Indeed, it does work now. Magic.
>
> Anything else?
LGTM if you remove t.Skipped()
I would have liked to have been given a chance to look at this before ...
11 years, 11 months ago
(2013-07-29 17:16:01 UTC)
#10
Message was sent while issue was closed.
I would have liked to have been given a chance to look at this before it was
submitted.
Why is interface{} special? Why do we not allow any argument type to which x can
be assigned?
Why are there only tests on amd64?
On Mon, Jul 29, 2013 at 9:16 PM, <rsc@golang.org> wrote: > I would have liked ...
11 years, 11 months ago
(2013-07-29 17:29:49 UTC)
#11
On Mon, Jul 29, 2013 at 9:16 PM, <rsc@golang.org> wrote:
> I would have liked to have been given a chance to look at this before it
> was submitted.
>
> Why is interface{} special? Why do we not allow any argument type to
> which x can be assigned?
There are 2 use cases:
1. Concrete finalizer for concrete type -- this is where current
finalizer is used.
2. Generic reflect-based programming -- this is where interface{}
finalizer is necessary.
> Why are there only tests on amd64?
Finalizer tests are flaky on 32-bits because of conservative GC. We
use such check in test/ for finalizer tests as well.
On 2013/07/29 17:29:49, dvyukov wrote: > On Mon, Jul 29, 2013 at 9:16 PM, <mailto:rsc@golang.org> ...
11 years, 11 months ago
(2013-07-29 20:12:03 UTC)
#12
Message was sent while issue was closed.
On 2013/07/29 17:29:49, dvyukov wrote:
> On Mon, Jul 29, 2013 at 9:16 PM, <mailto:rsc@golang.org> wrote:
> > I would have liked to have been given a chance to look at this before it
> > was submitted.
If my impatience caused trouble, I apologise.
> > Why is interface{} special? Why do we not allow any argument type to
> > which x can be assigned?
>
> There are 2 use cases:
> 1. Concrete finalizer for concrete type -- this is where current
> finalizer is used.
> 2. Generic reflect-based programming -- this is where interface{}
> finalizer is necessary.
Well, it would be nice if SetFinalizer() accepted any f whose argument is an
interface implemented by x. I can imagine this finalizer quite easily:
func fin(x io.Closer) {
x.Close()
}
Not exactly idiomatic, but not unthinkable. Cleaner and more descriptive than
interface{}, and interface{} wouldn't feel like such a special case.
Some more stuff would have to be moved to the runtime package. The body of
reflect.implements() comes to mind, unless you want to go further than that
(AssignableTo? ConvertibleTo?). And some more digging around the type system.
But it does sound like a seperate issue from allowing finalizers to be used with
reflect.
https://codereview.appspot.com/11858043/diff/31001/src/pkg/runtime/mfinal_test.go File src/pkg/runtime/mfinal_test.go (right): https://codereview.appspot.com/11858043/diff/31001/src/pkg/runtime/mfinal_test.go#newcode83 src/pkg/runtime/mfinal_test.go:83: t.Errorf("Expected *bigValue from interface{} in finalizer, got %v", *i) ...
11 years, 9 months ago
(2013-09-19 23:18:40 UTC)
#15
Message was sent while issue was closed.
https://codereview.appspot.com/11858043/diff/31001/src/pkg/runtime/mfinal_tes...
File src/pkg/runtime/mfinal_test.go (right):
https://codereview.appspot.com/11858043/diff/31001/src/pkg/runtime/mfinal_tes...
src/pkg/runtime/mfinal_test.go:83: t.Errorf("Expected *bigValue from interface{}
in finalizer, got %v", *i)
If I read this correctly the type "*bigValue" was expected. If that is the case
the printf verb "%v" should probably be replaced with "%T" and "*i" with "i"?
t.Errorf("Expected *bigValue from interface{} in finalizer, got %T", i)
https://codereview.appspot.com/11858043/diff/31001/src/pkg/runtime/mfinal_tes...
src/pkg/runtime/mfinal_test.go:85: if i.fill != 0xDEADBEEFDEADBEEF && i.it !=
true && i.up != "It matters not how strait the gate" {
Currently the test will only fail if all values are incorrect. What if one is
incorrect? Either "||" should be used instead of "&&" but I would rather want to
split the test into three different ones to give better error reporting.
Currently "%d" is an invalid printf verb for "*i".
What is the expected output if this fails?
Suggested replacement:
if i.fill != 0xDEADBEEFDEADBEEF {
t.Errorf("Expected %d, got %d.", 0xDEADBEEFDEADBEEF, i.fill)
}
if i.it != true {
t.Errorf("Expected %t, got %t.", true, i.it)
}
if i.up != "It matters not how strait the gate" {
t.Errorf("Expected %q, got %q.", "It matters not how strait the gate", i.up)
}
If these tests are rewritten in the future it would be nice to make them table
driven instead, this would reduce duplicate entries of strings such as: "It
matters not how strait the gate" (which can lead to typos).
Issue 11858043: code review 11858043: runtime: allow SetFinalizer with a func(interface{})
(Closed)
Created 11 years, 11 months ago by peted
Modified 11 years, 9 months ago
Reviewers: rsc, fresh.grass.yum
Base URL:
Comments: 32