FAQ
This is the play code:
http://play.golang.org/p/xSQfceJ7hC

type TB int
  func (t TB) Error(args ...interface{}) {}
...
func (t TB) Skipped() bool { return false }
  func (t TB) private() {}
  var tb testing.TB = new(TB)

Error message:

prog.go:28: cannot use new(TB) (type *TB) as type testing.TB in assignment:
*TB does not implement testing.TB (missing testing.private method)
have private()
want testing.private()
[process exited with non-zero status]

But I think the `TB` implement testing.TB.

Thie `testing.TB` with `.private()` is not a really private interface.

I we need a really private interface, we can define the inteface like this:

type privateType int

type TB interface {
private(privateType)
}

The `privateType` is a really private type, so the outside user can't define
a `private(privateType)` method for the private `testing.TB` interface.

Thanks.


--
https://chai2010.github.com/

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

Search Discussions

  • Jan Mercl at Sep 18, 2014 at 7:58 am

    On Thu, Sep 18, 2014 at 9:49 AM, chai2010 wrote:
    But I think the `TB` implement testing.TB.
    Interfaces having unexported methods cannot be implemented outside the
    declaring package. In this case, testing.TB can be implemented only by
    types declared in package testing.

    -j

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

    On Thursday, September 18, 2014 12:58:37 AM UTC-7, Jan Mercl wrote:
    testing.TB can be implemented only by types declared in package testing.

    Not true. See http://play.golang.org/p/4VSdjDf9si

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jan Mercl at Sep 18, 2014 at 8:19 am

    On Thu, Sep 18, 2014 at 10:10 AM, Islan Dberry wrote:
    Not true. See http://play.golang.org/p/4VSdjDf9si
    Not true. See http://play.golang.org/p/LCFMs_Scbe and click "Run".

    -j

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dan Kortschak at Sep 18, 2014 at 12:47 pm
    Is private ever called within testing? It doesn't seem so, so there is
    no real restriction on implementing the other parts. It's willfully
    ignoring the DO NOT ENTER sign, but that's what people do.
    On Thu, 2014-09-18 at 10:18 +0200, Jan Mercl wrote:
    Not true. See http://play.golang.org/p/LCFMs_Scbe and click "Run".

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Sep 18, 2014 at 3:15 pm

    On Thu, Sep 18, 2014 at 5:47 AM, Dan Kortschak wrote:
    Is private ever called within testing? It doesn't seem so, so there is
    no real restriction on implementing the other parts. It's willfully
    ignoring the DO NOT ENTER sign, but that's what people do.
    See the comment in the source code.

      // A private method to prevent users implementing the
      // interface and so future additions to it will not
      // violate Go 1 compatibility.
      private()

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Roger peppe at Sep 18, 2014 at 5:37 pm

    On 18 September 2014 16:14, Ian Lance Taylor wrote:
    On Thu, Sep 18, 2014 at 5:47 AM, Dan Kortschak
    wrote:
    Is private ever called within testing? It doesn't seem so, so there is
    no real restriction on implementing the other parts. It's willfully
    ignoring the DO NOT ENTER sign, but that's what people do.
    See the comment in the source code.

    // A private method to prevent users implementing the
    // interface and so future additions to it will not
    // violate Go 1 compatibility.
    private()
    It's perhaps interesting that even though we now know that this
    doesn't prevent users implementing the interface, it does
    actually succeed in its original aim, because anyone that
    implements the interface must at least embed that
    interface, so must gain the benefit of any new exported methods
    there. (They probably won't do the right thing of course,
    but at least the programs will compile)

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dan Kortschak at Sep 18, 2014 at 8:50 pm
    Yes, aware of that. It is not called though as far as I can see.
    On 19/09/2014, at 12:44 AM, "Ian Lance Taylor" wrote:

    On Thu, Sep 18, 2014 at 5:47 AM, Dan Kortschak
    wrote:
    Is private ever called within testing? It doesn't seem so, so there is
    no real restriction on implementing the other parts. It's willfully
    ignoring the DO NOT ENTER sign, but that's what people do.
    See the comment in the source code.

    // A private method to prevent users implementing the
    // interface and so future additions to it will not
    // violate Go 1 compatibility.
    private()

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Sep 18, 2014 at 9:26 pm

    On Thu, Sep 18, 2014 at 1:50 PM, Dan Kortschak wrote:
    Yes, aware of that. It is not called though as far as I can see.
    It's not called. Merely by existing it ensures that no other code can
    implement the testing.TB interface. That is the goal. There is no
    reason to actually call it.

    (It's true that other code can implement the interface using
    inheritance, but that's OK because it can't cause that code to break.)

    Ian
    On 19/09/2014, at 12:44 AM, "Ian Lance Taylor" wrote:

    On Thu, Sep 18, 2014 at 5:47 AM, Dan Kortschak
    wrote:
    Is private ever called within testing? It doesn't seem so, so there is
    no real restriction on implementing the other parts. It's willfully
    ignoring the DO NOT ENTER sign, but that's what people do.
    See the comment in the source code.

    // A private method to prevent users implementing the
    // interface and so future additions to it will not
    // violate Go 1 compatibility.
    private()

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Chai2010 at Sep 18, 2014 at 11:32 pm

    2014-09-19 5:26 GMT+08:00 Ian Lance Taylor <iant@golang.org>:

    On Thu, Sep 18, 2014 at 1:50 PM, Dan Kortschak
    wrote:
    Yes, aware of that. It is not called though as far as I can see.
    It's not called. Merely by existing it ensures that no other code can
    implement the testing.TB interface. That is the goal. There is no
    reason to actually call it.

    (It's true that other code can implement the interface using
    inheritance, but that's OK because it can't cause that code to break.)
    Does the spec have docs for interface's private method ?
    Ian
    On 19/09/2014, at 12:44 AM, "Ian Lance Taylor" wrote:

    On Thu, Sep 18, 2014 at 5:47 AM, Dan Kortschak
    wrote:
    Is private ever called within testing? It doesn't seem so, so there is
    no real restriction on implementing the other parts. It's willfully
    ignoring the DO NOT ENTER sign, but that's what people do.
    See the comment in the source code.

    // A private method to prevent users implementing the
    // interface and so future additions to it will not
    // violate Go 1 compatibility.
    private()

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.


    --
    https://chai2010.github.com/

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Sep 19, 2014 at 12:26 am

    On Thu, Sep 18, 2014 at 4:32 PM, chai2010 wrote:

    2014-09-19 5:26 GMT+08:00 Ian Lance Taylor <iant@golang.org>:
    On Thu, Sep 18, 2014 at 1:50 PM, Dan Kortschak
    wrote:
    Yes, aware of that. It is not called though as far as I can see.
    It's not called. Merely by existing it ensures that no other code can
    implement the testing.TB interface. That is the goal. There is no
    reason to actually call it.

    (It's true that other code can implement the interface using
    inheritance, but that's OK because it can't cause that code to break.)
    Does the spec have docs for interface's private method ?
    http://golang.org/ref/spec#Uniqueness_of_identifiers

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Chai2010 at Sep 19, 2014 at 2:35 am

    2014-09-19 8:26 GMT+08:00 Ian Lance Taylor <iant@golang.org>:
    On Thu, Sep 18, 2014 at 4:32 PM, chai2010 wrote:


    2014-09-19 5:26 GMT+08:00 Ian Lance Taylor <iant@golang.org>:
    On Thu, Sep 18, 2014 at 1:50 PM, Dan Kortschak
    wrote:
    Yes, aware of that. It is not called though as far as I can see.
    It's not called. Merely by existing it ensures that no other code can
    implement the testing.TB interface. That is the goal. There is no
    reason to actually call it.

    (It's true that other code can implement the interface using
    inheritance, but that's OK because it can't cause that code to break.)
    Does the spec have docs for interface's private method ?
    http://golang.org/ref/spec#Uniqueness_of_identifiers
    Thank you, Ian :)

    Ian


    --
    https://chai2010.github.com/

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Chai2010 at Sep 19, 2014 at 3:23 am
    I create a new play code:
    http://play.golang.org/p/cHxD0np4Or

    package main_test

    import (
    "fmt"
    "testing"
    )

    func TestTB(t *testing.T) {
    testTB(&TB{t})
    }

    func testTB(t testing.TB) {
    t.Fatal("foo")
    }

    type TB struct {
    testing.TB
    }

    func (p *TB) Fatal(args ...interface{}) {
    fmt.Println("TB.Fatal disabled!")
    }

    Output:

    TB.Fatal disabled!
    PASS
    ok github.com/chai2010/gopkg/image/big/a 0.140s

    The `testing.TB` is not a really private interface,
    We can implementing the `testing.TB` interface.
    Just like `TB.Fatal`.


    2014-09-19 10:35 GMT+08:00 chai2010 <chaishushan@gmail.com>:

    2014-09-19 8:26 GMT+08:00 Ian Lance Taylor <iant@golang.org>:
    On Thu, Sep 18, 2014 at 4:32 PM, chai2010 wrote:


    2014-09-19 5:26 GMT+08:00 Ian Lance Taylor <iant@golang.org>:
    On Thu, Sep 18, 2014 at 1:50 PM, Dan Kortschak
    wrote:
    Yes, aware of that. It is not called though as far as I can see.
    It's not called. Merely by existing it ensures that no other code can
    implement the testing.TB interface. That is the goal. There is no
    reason to actually call it.

    (It's true that other code can implement the interface using
    inheritance, but that's OK because it can't cause that code to break.)
    Does the spec have docs for interface's private method ?
    http://golang.org/ref/spec#Uniqueness_of_identifiers
    Thank you, Ian :)

    Ian


    --
    https://chai2010.github.com/

    --
    https://chai2010.github.com/

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Sep 19, 2014 at 2:36 pm

    On Thu, Sep 18, 2014 at 8:23 PM, chai2010 wrote:
    The `testing.TB` is not a really private interface,
    We can implementing the `testing.TB` interface.
    Just like `TB.Fatal`.
    The point is that if you do that, and we then add methods to
    testing.TB, your code will not break.

    If we did not have the private method, then you could write your own
    type with your own methods that implemented everything in testing.TB,
    and you could use your type, but then when we added methods to
    testing.TB, your code would break.

    In other words, exactly what the comment says:

      // A private method to prevent users implementing the
      // interface and so future additions to it will not
      // violate Go 1 compatibility.

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dan Kortschak at Sep 18, 2014 at 11:52 pm

    On Thu, 2014-09-18 at 14:26 -0700, Ian Lance Taylor wrote:
    It's not called. Merely by existing it ensures that no other code can
    implement the testing.TB interface. That is the goal. There is no
    reason to actually call it.
    Yes. That was exactly my point. It's a sign that says DO NOT ENTER
    (metaphorically). People are free to ignore it, because it is ignorable,
    if (as you say below) people embed a testing.TB of some variety.

    (It's true that other code can implement the interface using
    inheritance, but that's OK because it can't cause that code to break.)
    Yes.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Roger peppe at Sep 18, 2014 at 1:49 pm

    On 18 September 2014 09:18, Jan Mercl wrote:
    On Thu, Sep 18, 2014 at 10:10 AM, Islan Dberry wrote:
    Not true. See http://play.golang.org/p/4VSdjDf9si
    Not true. See http://play.golang.org/p/LCFMs_Scbe and click "Run".
    Jan, your code just means that external packages can't call the private
    method, not that the implementation isn't implemented (if private was
    called inside the testing package, it would work fine).

    I don't really see why TB contains the private method tbh - it isn't used
    by any of the exported testing functions or methods.

    Probably not worth implementing though - just define your own.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jesse McNelis at Sep 18, 2014 at 7:59 am

    On Thu, Sep 18, 2014 at 5:49 PM, chai2010 wrote:
    prog.go:28: cannot use new(TB) (type *TB) as type testing.TB in assignment:
    *TB does not implement testing.TB (missing testing.private method)
    have private()
    want testing.private()
    [process exited with non-zero status]

    But I think the `TB` implement testing.TB.
    It can't because the method required to implement the interface is
    testing.private() not private().
    That is, it needs to be a method called private() on a type defined in
    the testing 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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedSep 18, '14 at 7:49a
activeSep 19, '14 at 2:36p
posts17
users7
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase