Re: [go-nuts] New methods for imported packages

[chris dollin]

On 8 September 2012 19:44, Lucas Sampaio <magal...@gmail.com> wrote:
> Hello guys,
>
> I'm learning Go and making some experiments... but I have a question, is
> there any way to create a new method for a imported struct? Something like:
>
> func (t *testing.T) DoIT(a, b int) int {
> return a+b
> }

No.

(How to get round that depends on what you'd really be
trying to do. The semantic reason to define methods is
so that things implement interfaces; sometimes what
tou can do is define a new type and embed the old one in
it and exploits its methods that way.)

Chris

--
Chris "allusive" Dollin

[Lucas Sampaio]

Wll, that's a bit sad read that, but no problem =S

Att,

Lucas S. Magalhães
Tel.: (27) 9942-8278
Skype: lucassmagal

2012/9/8 chris dollin <ehog....@googlemail.com>

[Jan Mercl]

On Sat, Sep 8, 2012 at 8:44 PM, Lucas Sampaio <magal...@gmail.com> wrote:
> I'm learning Go and making some experiments... but I have a question, is
> there any way to create a new method for a imported struct? Something like:
>
> func (t *testing.T) DoIT(a, b int) int {
> return a+b
> }

http://play.golang.org/p/bRTx6SJEqi

-j

[Lucas Sampaio]

I changed your code a little: http://play.golang.org/p/UVqoSASuVa

Unfortunately, I can't use that in 'go test', it only accepts t *testing.T =S

Lucas S. Magalhães
Tel.: (27) 9942-8278
Skype: lucassmagal

2012/9/8 Jan Mercl <0xj...@gmail.com>

[Lucas Sampaio]

Is there any chance to see it implemented in next releases?

Lucas S. Magalhães
Tel.: (27) 9942-8278
Skype: lucassmagal

2012/9/8 Lucas Sampaio <magal...@gmail.com>

[Rémy Oudompheng]

On 2012/9/8 Lucas Sampaio <magal...@gmail.com> wrote:
> I changed your code a little: http://play.golang.org/p/UVqoSASuVa
>
> Unfortunately, I can't use that in 'go test', it only accepts t *testing.T

What are you trying to do? You can write functions instead of methods.

Rémy.

[Rémy Oudompheng]

On 2012/9/8 Lucas Sampaio <magal...@gmail.com> wrote:

> Is there any chance to see it implemented in next releases?

I don't think so, why would you want that ?

Rémy.

[Francisco Souza]

On Sat, Sep 8, 2012 at 4:28 PM, Lucas Sampaio <magal...@gmail.com> wrote:
> I changed your code a little: http://play.golang.org/p/UVqoSASuVa
>
> Unfortunately, I can't use that in 'go test', it only accepts t *testing.T
> =S

What are you trying to do? Why are you declaring a method for a T struct?

--
~f

[Lucas Sampaio]

Nothing special, actually. I'm just trying to learn how to extend testing package... something like this, but instead of assert.Equal(t, a, b), make something like t.assertEqual(a, b).

But, again, nothing serious... just for fun & learning.

Lucas S. Magalhães
Tel.: (27) 9942-8278
Skype: lucassmagal

2012/9/8 Francisco Souza <f...@souza.cc>

On Sat, Sep 8, 2012 at 4:28 PM, Lucas Sampaio <magal...@gmail.com> wrote:
> I changed your code a little: http://play.golang.org/p/UVqoSASuVa
>
> Unfortunately, I can't use that in 'go test', it only accepts t *testing.T
> =S

[Francisco Souza]

On Sat, Sep 8, 2012 at 4:46 PM, Lucas Sampaio <magal...@gmail.com> wrote:
> Nothing special, actually. I'm just trying to learn how to extend testing
> package... something like this, but instead of assert.Equal(t, a, b), make
> something like t.assertEqual(a, b).

That's not possible, and I don't think it will change in go1.


--
~f

[Steven Degutis]

Oh hey look, that guy independently wrote nearly the exact same library as my go.assert. How crazy.

-Steven

[Jan Mercl]

On Sat, Sep 8, 2012 at 9:46 PM, Lucas Sampaio <magal...@gmail.com> wrote:
> Nothing special, actually. I'm just trying to learn how to extend testing
> package... something like this, but instead of assert.Equal(t, a, b), make
> something like t.assertEqual(a, b).

// untested code

type myT struct {
*testing.T
}

func (t myT) assertEqual(foo, bar baz) {
if foo != bar {
t.Error(foo, "!=", bar)
}
}

func TestQux(t *testing.T) {
u := myT{t}
err, got := what()
if err != nil {
t.Fatal(err)
}

!u.assertWhatever(got, expected)
}

... but note how rigid 'assert*' is - it cannot easily provide more
context nor decision logic than


func TestQux(t *testing.T) {
err, got := what()
if err != nil {
t.Fatal(err)
}

if foo != bar {
switch {
case foo - bar < 0.01:
t.Log("foo not exactly bar", foo, bar)
case foo < bar:
t.Error("foo < bar", foo, bar)
case foo > bar:
t.Fatal("foo > bar!", foo, bar)
}
}
}

IOW, you will not find too much assert* like functions in Go code out there ;-)

-j