Re: [go-nuts] Interface embedding

3. We want to be resilient when other methods are added to the DatastoreClient interface so that the code will still compile when that happens. That was my guess too: that it's a tradeoff between safety and future compatibility. This allows your library users to use newer versions of the pr

Re: [go-nuts] Interface embedding

On Tue, 29 Aug 2023 at 13:35, Remko Tronçon wrote: > The Google Cloud Go library contains the following code (See > https://github.com/googleapis/google-cloud-go/blob/38a040e213cc8af5b01b3afe422481493f54382f/datastore/client.go#L36 > ) > > // datastoreClient is a wrapper for the pb.DatastoreC

[go-nuts] Interface embedding

The Google Cloud Go library contains the following code (See https://github.com/googleapis/google-cloud-go/blob/38a040e213cc8af5b01b3afe422481493f54382f/datastore/client.go#L36 ) // datastoreClient is a wrapper for the pb.DatastoreClient type datastoreClient struct { // Embed so we stil

Re: [go-nuts] Interface() method of reflect.Value sometimes allocates, sometimes not

On Mon, Jun 26, 2023 at 8:28 AM christoph...@gmail.com wrote: > > I'm implementing a value encoder similar to gob. While bench-marking my code > against gob, I noticed some unexpected memory allocations with a particular > type of data. > > See this minimal code example in the go playground > h

[go-nuts] Interface() method of reflect.Value sometimes allocates, sometimes not

I'm implementing a value encoder similar to gob. While bench-marking my code against gob, I noticed some unexpected memory allocations with a particular type of data. See this minimal code example in the go playground https://go.dev/play/p/4rm-kCtD274 There is a simple function foo() receiving

Re: [go-nuts] interface implementing subset not compatible

Hi, this is answered (to a degree) in the FAQ: https://golang.org/doc/faq#covariant_types On Mon, Feb 1, 2021 at 2:51 PM Miha Vrhovnik wrote: > > I'm trying to put external library under the interface but it seems that > this is not possible the way I thought it would be... > > My interfaces a

[go-nuts] interface implementing subset not compatible

I'm trying to put external library under the interface but it seems that this is not possible the way I thought it would be... My interfaces are as following... *type Beginner interface {Begin(ctx context.Context) (Tx, error)}type Querier interface {Exec(ctx context.Cont

Re: [go-nuts] Interface arguments to generic functions

On Tue, Jan 19, 2021 at 10:02 PM burak serdar wrote: > > As a generic-function writer, I do not know if the argument will be an > interface or a concrete type. I don't want to check if it is > zero-value, I want to check if it is nil, because I don't want it to > panic. Other people in this threa

Re: [go-nuts] Interface arguments to generic functions

On Tue, Jan 19, 2021 at 7:06 PM burak serdar wrote: > However, there is no way for P to check if x is nil. This does not compile: > > func P[T fmt.Stringer](x T) { > if x!=nil { > fmt.Println(x) > } > } Is this doing what you want? func P[T fmt.Stringer](x T) { if fmt.St

Re: [go-nuts] Interface arguments to generic functions

On Tue, Jan 19, 2021 at 10:37 PM Ian Lance Taylor wrote: > > On Tue, Jan 19, 2021 at 8:02 PM burak serdar wrote: > > > > On Tue, Jan 19, 2021 at 8:38 PM Ian Lance Taylor wrote: > > > > > > On Tue, Jan 19, 2021 at 7:06 PM burak serdar wrote: > > > > > > > > In the following program, it is valid

Re: [go-nuts] Interface arguments to generic functions

On Tue, 2021-01-19 at 21:38 -0800, Ian Lance Taylor wrote: > On Tue, Jan 19, 2021 at 8:41 PM Dan Kortschak > wrote: > > > > Would that work for non-comparable types? Say the T has an > > underlying > > []int type, then the comparison is not against nil and you end up > > with > > a panic. > > >

Re: [go-nuts] Interface arguments to generic functions

On Tue, Jan 19, 2021 at 8:41 PM Dan Kortschak wrote: > > On Tue, 2021-01-19 at 19:38 -0800, Ian Lance Taylor wrote: > > On Tue, Jan 19, 2021 at 7:06 PM burak serdar > > wrote: > > > > > > In the following program, it is valid to pass an interface to > > > function P: > > > > > > func P[T fmt.Stri

Re: [go-nuts] Interface arguments to generic functions

On Tue, Jan 19, 2021 at 8:02 PM burak serdar wrote: > > On Tue, Jan 19, 2021 at 8:38 PM Ian Lance Taylor wrote: > > > > On Tue, Jan 19, 2021 at 7:06 PM burak serdar wrote: > > > > > > In the following program, it is valid to pass an interface to function P: > > > > > > func P[T fmt.Stringer](x T

Re: [go-nuts] Interface arguments to generic functions

On Tue, 2021-01-19 at 19:38 -0800, Ian Lance Taylor wrote: > On Tue, Jan 19, 2021 at 7:06 PM burak serdar > wrote: > > > > In the following program, it is valid to pass an interface to > > function P: > > > > func P[T fmt.Stringer](x T) { > > fmt.Println(x) > > } > > > > func main() { > >

Re: [go-nuts] Interface arguments to generic functions

On Tue, Jan 19, 2021 at 8:38 PM Ian Lance Taylor wrote: > > On Tue, Jan 19, 2021 at 7:06 PM burak serdar wrote: > > > > In the following program, it is valid to pass an interface to function P: > > > > func P[T fmt.Stringer](x T) { > > fmt.Println(x) > > } > > > > func main() { > > var v f

Re: [go-nuts] Interface arguments to generic functions

On Tue, Jan 19, 2021 at 7:06 PM burak serdar wrote: > > In the following program, it is valid to pass an interface to function P: > > func P[T fmt.Stringer](x T) { > fmt.Println(x) > } > > func main() { > var v fmt.Stringer > P(v) > } > > However, there is no way for P to check if x is ni

[go-nuts] Interface arguments to generic functions

In the following program, it is valid to pass an interface to function P: func P[T fmt.Stringer](x T) { fmt.Println(x) } func main() { var v fmt.Stringer P(v) } However, there is no way for P to check if x is nil. This does not compile: func P[T fmt.Stringer](x T) { if x!=nil {

[go-nuts] Interface Fields

I'm doing some due-diligence and wondering if there's any old topics about extending interfaces to support field sets. ie. type WithID interface { ID string } type X struct { ID string } type Y struct { ID string } func PrintID(item WithID) { fmt.Println(item.ID) } In the above the PrintID

Re: [go-nuts] Interface definition as type alias

The only real downsides, I think, are that compiler errors gets harder to read: https://github.com/golang/go/issues/21866 And likewise, that the name won't appear at runtime, so if you print things using `reflect`, the result will be less readable. I think there are cases where it has advantages,

[go-nuts] Interface definition as type alias

TLDR: Why should I NOT the alias form `type ... = interface {...}` instead of the standard `type ... interface {...}` for interface declarations? The extended question: The normal type definition for an interface in go would be `type TypeName interface {...}`. This results in a new type, which

[go-nuts] interface vs functions for mocking

Hi While writing unit test, what should be the preferred way to mock an external(database, http...) call, *function based approach* or *interface based approach?* I don't understand when to use function way and when to use interface way. Which one is more idiomatic Golang way if I am writing my we

Re: [go-nuts] Interface method return other interface?

Thank you all for your feedback and input. Shame on me that I didn't look hard enough through the stdlib for getting some examples, but thanks Axel for pointing that out. On Thu, Oct 10, 2019 at 3:11 AM Robert Engels wrote: > > Ugh. Every time I see that I cringe > > > On Oct 9, 2019, at 7:58

Re: [go-nuts] Interface method return other interface?

Ugh. Every time I see that I cringe > On Oct 9, 2019, at 7:58 PM, burak serdar wrote: > > On Wed, Oct 9, 2019 at 5:48 PM 'Axel Wagner' via golang-nuts > wrote: >> >> There's loads of precedence in the stdlib: >> >> https://godoc.org/net/http/#FileSystem.Open >> https://godoc.org/net/http

Re: [go-nuts] Interface method return other interface?

On Wed, Oct 9, 2019 at 5:48 PM 'Axel Wagner' via golang-nuts wrote: > > There's loads of precedence in the stdlib: > > https://godoc.org/net/http/#FileSystem.Open > https://godoc.org/net/http#File.Stat > https://godoc.org/net#Conn.LocalAddr > https://godoc.org/database/sql/driver/#Driver.Open > ht

Re: [go-nuts] Interface method return other interface?

There's loads of precedence in the stdlib: https://godoc.org/net/http/#FileSystem.Open https://godoc.org/net/http#File.Stat https://godoc.org/net#Conn.LocalAddr https://godoc.org/database/sql/driver/#Driver.Open https://godoc.org/image#Image.ColorModel https://godoc.org/reflect/#Type.Elem And don'

Re: [go-nuts] Interface method return other interface?

I always find accept interface and return struct to be very useful. It makes the code more cleaner. On Wed, 9 Oct 2019 at 9:40 AM, Martin Palma wrote: > I'm wondering If it is ok (or good Go code) if an interface method returns > an other interface? Here an example: > > type Querier interface

[go-nuts] Interface method return other interface?

I'm wondering If it is ok (or good Go code) if an interface method returns an other interface? Here an example: type Querier interface { Query() string } type Decoder interface { DecodeAndValidate() Querier } -- You received this message because you are subscribed to the Google Groups "gol

Re: [go-nuts] interface{private()}

On Thu, Jun 20, 2019 at 5:49 PM Gert wrote: > > Thanks, does the go standard library have a use case where a private() > function in a interface is needed? Looking for more examples to understand > the benefit to do so. Yes, in the go/ast package (and possibly elsewhere, but that's the example

Re: [go-nuts] interface{private()}

Thanks, does the go standard library have a use case where a private() function in a interface is needed? Looking for more examples to understand the benefit to do so. On Friday, June 21, 2019 at 2:36:01 AM UTC+2, Ian Lance Taylor wrote: > > On Thu, Jun 20, 2019 at 5:25 PM Gert > > wrote: > >

Re: [go-nuts] interface{private()}

On Thu, Jun 20, 2019 at 5:25 PM Gert wrote: > > Trying to get my mind around why the private() function is necessary here. I > fail to understand the comment provided > > type Geometry interface { > GeoJSONType() string > Dimensions() int // e.g. 0d, 1d, 2d > Bound() Bound > > // requirin

[go-nuts] interface{private()}

Trying to get my mind around why the private() function is necessary here. I fail to understand the comment provided type Geometry interface { GeoJSONType() string Dimensions() int // e.g. 0d, 1d, 2d Bound() Bound // requiring because sub package type switch over all possible types. pr

[go-nuts] Interface in go-plugins

Hi, I am using plugin package to implement a feature of my project recently, But some behavior confuses me. #1 interface main.go: type PluginType interface{ GetVersion() string } func main() { plugFile, err := plugin.Open(filepath.Join("plugins", "plugin_sample.so")) if err != nil { fmt.Println(

Re: [go-nuts] interface array and ... operator

In my defense, neither A() nor B() complies in the actual example given. If you comment out A() you will see that B() then fails to compile. If B() is fixed by replacing "i = append(i, s)" with "i = append(i, sa)", then it succeeds. I believe that is due to the clause I referenced in my mistak

Re: [go-nuts] interface array and ... operator

No need. I was just getting very confused trying to follow. > On Oct 25, 2018, at 10:59 AM, jake6...@gmail.com wrote: > > Yes. I was completely mistaken in my post. Apologies. > >> On Wednesday, October 24, 2018 at 12:14:36 PM UTC-4, robert engels wrote: >> I quote >> >> So in the OP's exampl

Re: [go-nuts] interface array and ... operator

Oops. Please ignore my entire post. Misunderstood completely. On Wednesday, October 24, 2018 at 11:55:18 AM UTC-4, Jake Montgomery wrote: > > That is correct. The relevant part of > https://golang.org/ref/spec#Passing_arguments_to_..._parameters is where > it says: " respective parameter passin

Re: [go-nuts] interface array and ... operator

Yes. I was completely mistaken in my post. Apologies. On Wednesday, October 24, 2018 at 12:14:36 PM UTC-4, robert engels wrote: > > I quote > > So in the OP's example https://play.golang.org/p/59bpr8TCIge, the > function A() is assigning a []string to the variadic ...[]interface{}. > Since stri

Re: [go-nuts] interface array and ... operator

Eh, actially the other discusser said that. Me not. I explained why A does not work. On Wed, Oct 24, 2018, 18:08 Jan Mercl <0xj...@gmail.com> wrote: > Nobody said that. > > On Wed, Oct 24, 2018, 18:04 robert engels wrote: > >> I’m confused… it is A that doesn’t work, and B works… everyone keeps

Re: [go-nuts] interface array and ... operator

I quote So in the OP's example https://play.golang.org/p/59bpr8TCIge , the function A() is assigning a []string to the variadic ...[]interface{}. Since string is assignable to interface{}. this is fine. The function B() is assigning a []interface{} to the

Re: [go-nuts] interface array and ... operator

Nobody said that. On Wed, Oct 24, 2018, 18:04 robert engels wrote: > I’m confused… it is A that doesn’t work, and B works… everyone keeps > stating that B doesn’t work and A works…. > > On Oct 24, 2018, at 10:55 AM, jake6...@gmail.com wrote: > > > That is correct. The relevant part of > https://

Re: [go-nuts] interface array and ... operator

I’m confused… it is A that doesn’t work, and B works… everyone keeps stating that B doesn’t work and A works…. > On Oct 24, 2018, at 10:55 AM, jake6...@gmail.com wrote: > > That is correct. The relevant part of > https://golang.org/ref/spec#Passing_arguments_to_..._parameters >

Re: [go-nuts] interface array and ... operator

That is correct. The relevant part of https://golang.org/ref/spec#Passing_arguments_to_..._parameters is where it says: " respective parameter passing rules apply". This links to https://golang.org/ref/spec#Passing_arguments_to_

Re: [go-nuts] interface array and ... operator

But it is the varadic one that works according to OP. > On Oct 24, 2018, at 4:19 AM, Jan Mercl <0xj...@gmail.com> wrote: > > On Wed, Oct 24, 2018 at 7:34 AM Mayank Jha wrote: > > > why does A() not work while B works here, > > https://play.golang.org/p/59bpr8TCIge > > Type mismatch. The com

Re: [go-nuts] interface array and ... operator

On Wed, Oct 24, 2018 at 7:34 AM Mayank Jha wrote: > why does A() not work while B works here, https://play.golang.org/p/59bpr8TCIge Type mismatch. The compiler is clear about it: prog.go:8:12: cannot use s (type []string) as type []interface {} in append >From https://golang.org/ref/sp

[go-nuts] interface array and ... operator

why does A() not work while B works here, https://play.golang.org/p/59bpr8TCIge -- 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...@googlegro

Re: [go-nuts] interface question

How can i get a list about which interface is implemented by this struct methods? (Because in Go there is no explicit interface declaration.) os.Open returns an os.File (https://golang.org/pkg/os/#Open). os.File (https://golang.org/pkg/os/#File) has functions and methods listed in the index o

[go-nuts] interface question

Hi Beginner question I want to use this : func Open(name string) (*File, error) I would like to us *File as return value. File is declared as : type File struct { *file // os specific } I understand it. BUT How can i get a list about which interface is implemented by this struct method

Re: [go-nuts] Interface ????

On Tue, Feb 27, 2018 at 4:25 PM wrote: > Why doesn't work this : Because types []string and []interface{} are different and not assignable to each other. > and Why does it work? : Because type string implements interface{} (as any other type does), string is assignable to a variable of type in

[go-nuts] Interface ????

*Hello* *A beginner question :* *Why doesn't work this :* package main import ( "fmt" ) func PrintAll(vals []interface{}) { for _, val := range vals { fmt.Println(val) } } func main() { names := []string{"stanley", "david", "oscar"} <-error

Re: [go-nuts] Interface value terminology

Just my personal usage/2¢: 1. An interface-value/The value of an interface 2. The dynamic value 3. The dynamic type x. Concrete type, to me, is a static type that is not an interface type. y. Concrete value, to me, might sometimes be used interchangeably with dynamic value. Or it might refer to th

Re: [go-nuts] Interface value terminology

I’ve adopted terminology from other OO languages and people seem to have understood me. > 1. the value of an interface (both parts), This is the “interface value”. > 2. the concrete value, The “boxed value”. > 3. the type descriptor. No need to talk about it specifically. Worst case, it is "

Re: [go-nuts] Interface value terminology

On Mon, Nov 27, 2017 at 9:13 AM Stefan Nilsson wrote: > My question. How do you refer to the following three concepts (and why): > > 1. the value of an interface (both parts), The value of/in the interface variable. Why: No alternative comes to my mind. > 2. the concrete value, The value of/in

[go-nuts] Interface value terminology

An interface value in Go consists of two parts: a concrete value and a type descriptor. What is the preferred terminology when talking about this? The language specification says "dynamic value" and "dynamic type". However, this doesn't seem to have caught on. The term "concrete value" seems t

Re: [go-nuts] interface{} as type []interface{}

On Fri, Nov 10, 2017 at 10:27 AM, Trig wrote: > Is it possible to have an interface{} as type []interface{}? Yep, you can store a slice of interface{} in an interface{} eg. // interface{} holding an []interface{} holding ints var a interface{} = []interface{}{1,2,3,4,5} https://play.golang.org/

[go-nuts] interface{} as type []interface{}

Is it possible to have an interface{} as type []interface{}? -- 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 op

[go-nuts] interface conversion fails: backends.Client is *mock.client, not *mock.client

I've been trying to debug a really strange issue and stuck believing it being a bug in the Go compiler toolchain. interface conversion: backends.Client is *mock.client, not *mock.client Steps to reproduce: $ cd $(mktemp -d) $ git clone https://github.com/leonklingele/pick -b interface-conversio

Re: [go-nuts] "interface{} says nothing", lets consider it destroys information

here is a solution to what i described in previous. The result of func mustNotErr(f func() (, error)) func() () {} is the transitivity of t -to> func (...) (..., *-*error) mustNotErr takes in input a func T with any inputs, and a *traling* error, returns in output, the func T *less* the trailing

Re: [go-nuts] "interface{} says nothing", lets consider it destroys information

so wise! thanks for those clarification. I did not deeply understand why it is called an identity func, and why it has to be this signature. It seems so narrowed to a specific case, makes me unhappy. Now, i realized that even if , for some specific cases, seems to solve some situations, it won

Re: [go-nuts] "interface{} says nothing", lets consider it destroys information

On Mon, Jul 17, 2017 at 11:07 AM wrote: > does it make sense to consider a "value type of any type that carries out > its input type" ? > Yes. This is called a "universal" and is related to the concept of parametrization by J. Reynolds. Your 'do' function is often called 'id' for the obvious re

[go-nuts] "interface{} says nothing", lets consider it destroys information

in func do(i interface{}) interface{} (return i), do says nothing because "interface{} says nothing", from the caller pov, it looses information at the return call, var x = "o" do(x) // <- return lost the track it was a string if you delegate that func to another func, it can t says anything

Re: [go-nuts] Interface-keyed maps and non-comparable dynamic key values

Just realised I accidentally replied to Ian off-list: > My question is why something that could be caught at compile time is not > > caught at compile time: > > I suspect mostly because nobody thought of it. > > That said, note that this in effect a language change. It is possible > to construct

Re: [go-nuts] ...interface{} vs interface{} + reflection

I'd say your case isn't dissimilar to this one: https://godoc.org/gopkg.in/mgo.v2#Iter.All >From a brief glance at your code, I'd think that using interface{} rather than []interface{} is a reasonable approach. It could actually save the conversion to []interface{} completely in some places (for e

[go-nuts] ...interface{} vs interface{} + reflection

I have a public API that takes `...interface{}` as an argument. (For reference: https://godoc.org/github.com/flimzy/kivik#DB.BulkDocs ) I'm considering changing this to instead take `interface{}` as an argument, then using reflection to: - Validate that the underlying type is an array - Co

Re: [go-nuts] interface assignment

Thanks for the clear explanation! 在 2017年5月1日星期一 UTC+8下午9:55:30，Ian Lance Taylor写道： > > On Mon, May 1, 2017 at 6:03 AM, feilengcui008 > wrote: > > > > I have made a little testing about interface assignment and searched > the > > source code about interface runtime functions like convI2I,

Re: [go-nuts] interface assignment

On Mon, May 1, 2017 at 6:03 AM, feilengcui008 wrote: > > I have made a little testing about interface assignment and searched the > source code about interface runtime functions like convI2I, and notice that > there are two situations where data may be copied or not: > (1) data not co

[go-nuts] interface assignment

Hey, All: I have made a little testing about interface assignment and searched the source code about interface runtime functions like convI2I, and notice that there are two situations where data may be copied or not: (1) data not copied: assign another* interface type* variable to t

Re: [go-nuts] Interface-keyed maps and non-comparable dynamic key values

> > IMO implementing such a compile check would be contrary to the "least > WTF" principle. Imagine something like > > type S struct { > f func() > } > > func (s S) Impl() {} > > func Foo() I { > return S{} > } > > m[Foo()] = true > > The compiler is able to check at compile ti

Re: [go-nuts] Interface-keyed maps and non-comparable dynamic key values

On Tue, 4 Apr 2017 07:27:17 -0700 Ian Lance Taylor wrote: > >> When you insert a value keyed by S{}, the compiler creates a value > >> of type I which has S as its dynamic type and S{} as its value. > >> > >> The program as speficied panics with > > > > > > Apologies if it wasn't clear from my or

Re: [go-nuts] Interface-keyed maps and non-comparable dynamic key values

On Tue, Apr 4, 2017 at 3:41 AM, Paul Jolly wrote: >> When you insert a value keyed by S{}, the compiler creates a value of >> type I which has S as its dynamic type and S{} as its value. >> >> The program as speficied panics with > > > Apologies if it wasn't clear from my original email, but I und

Re: [go-nuts] Interface-keyed maps and non-comparable dynamic key values

> > When you insert a value keyed by S{}, the compiler creates a value of > type I which has S as its dynamic type and S{} as its value. > > The program as speficied panics with > Apologies if it wasn't clear from my original email, but I understand why this panics; I further acknowledge the behav

Re: [go-nuts] Interface-keyed maps and non-comparable dynamic key values

On Tue, 4 Apr 2017 02:40:31 -0700 (PDT) Paul Jolly wrote: > *I couldn't find anything previously on the question below, but as > ever would appreciate any pointers to prior questions/issues etc.* > > Consider the following (playground > ): > > > packag

[go-nuts] Interface-keyed maps and non-comparable dynamic key values

*I couldn't find anything previously on the question below, but as ever would appreciate any pointers to prior questions/issues etc.* Consider the following (playground ): package main import ( "fmt" ) type S struct { f func() } func

[go-nuts] Interface help

I'm trying to better understand how to properly use interfaces and created this scenario: Let's say I have an 'evaluator' program, that over time will want to add more and more evaluations of a Go-NoGo nature (Nasa?) Here's want I was trying: // My Go-NoGo interface - method should return true

Re: [go-nuts] Interface vs first-class function

>From my point of view, the main difference is that interfaces are strictly more powerful, because you can't dynamically type convert a function type into something different. You can always make an interface from a function (e.g. http.HandlerFunc and the like) but not the other way around. This

[go-nuts] Interface vs first-class function

Hi, I am wondering from best practice point of view whether it is better to use interface or first-class function, especially considering that Go encourages the use of small interfaces. Here is an example: type SomethingDoer interface{ DoSomething(data Data) } func PerformWork(doer Somethin

[go-nuts] Interface Pitfalls and Harnessing io.Reader

I just put together some thoughts to try to help newcomers to Go start to grasp interfaces. It walks through some steps that I've seen people coming from languages like Perl go through. I'd really appreciate any any vetting, comments or critiques you could offer. https://jrub.in/golang-interfac

Re: [go-nuts] interface as valid method receivers ?

I think the original proposition is not to add default implementation for the methods in an interface. The proposal was just want to add extra methods to the interface. These methods will not get into the vtable of the interface. Yes, this can be implemented by package level function, but it is

Re: [go-nuts] interface as valid method receivers ?

On Wednesday, October 19, 2016 at 10:16:50 PM UTC+3, Jan Mercl wrote: > > On Wed, Oct 19, 2016 at 8:58 PM Viktor Kojouharov > wrote: > > > Not really, as this is all hypothetical, it might be implemented in a > way so that any type that wants to satisfy an interface with default > methods has

Re: [go-nuts] interface as valid method receivers ?

On Wed, Oct 19, 2016 at 8:58 PM Viktor Kojouharov wrote: > Not really, as this is all hypothetical, it might be implemented in a way so that any type that wants to satisfy an interface with default methods has to at least implement all non-default ones. That is to say, with the above example inte

Re: [go-nuts] interface as valid method receivers ?

On Wednesday, October 19, 2016 at 6:52:30 PM UTC+3, Jan Mercl wrote: > > > On Wed, Oct 19, 2016 at 5:40 PM Viktor Kojouharov > wrote: > > > That's just a default method implementation. There's nothing inherently > confusing about what gets called. If a concrete implementation exists, that > ge

Re: [go-nuts] interface as valid method receivers ?

The one way this could be possibly useful, in my opinion, would be to add methods to existing interfaces (from other packages no less), a la extensions in Objective-C (and Swift). So say extending io.Reader { ReadAll() ([]byte, error) } func (r io.Reader) ReadAll() ([]byte, error) { // implem

Re: [go-nuts] interface as valid method receivers ?

On Wed, 19 Oct 2016 08:40:51 -0700 (PDT) Viktor Kojouharov wrote: [...] > > type Foo interface { > > func DoSomething() > > } > > > > func (f Foo) DoSomething() { > > } > > > > var f Foo > > > > f.DoSomething() > > > > How do you propose to distinguish these two DoSomethi

Re: [go-nuts] interface as valid method receivers ?

On Wed, Oct 19, 2016 at 5:40 PM Viktor Kojouharov wrote: > That's just a default method implementation. There's nothing inherently confusing about what gets called. If a concrete implementation exists, that gets called, otherwise the default one does. But to assign something to f (of type Foo) i

Re: [go-nuts] interface as valid method receivers ?

On Tuesday, October 18, 2016 at 9:27:36 PM UTC+3, Konstantin Khomoutov wrote: > > On Tue, 18 Oct 2016 11:11:59 -0700 (PDT) > parais...@gmail.com wrote: > > > Obviously in Go this is a compile time error : > > > > type Foo interface {} > > > > > > func (f Foo) DoSomething(){} > > > I w

Re: [go-nuts] interface as valid method receivers ?

Why not make it a compiling time error? For example, for a struct: "type Foo has both field and method named DoSomething" type Foo struct { DoSomething func() } func (f Foo) DoSomething() { } And for interface version: type Foo interface { func DoSomething() } func (f Foo) DoSome

Re: [go-nuts] interface as valid method receivers ?

On Tue, 18 Oct 2016 11:11:59 -0700 (PDT) paraiso.m...@gmail.com wrote: > Obviously in Go this is a compile time error : > > type Foo interface {} > > > func (f Foo) DoSomething(){} > > > I wonder if there is some technical limitations that make it > undesirable or hard to implement, or it's j

[go-nuts] interface as valid method receivers ?

Obviously in Go this is a compile time error : type Foo interface {} func (f Foo) DoSomething(){} I wonder if there is some technical limitations that make it undesirable or hard to implement, or it's just that Go designers didn't think it is a relevant feature. I personally think there is

Re: [go-nuts] Interface{} constrains on specific types

The trick is to do this: Decl special_interface and then special_interface requires an unexported interface which you implement in the specific (new) types that you can store in the thing. On Fri, Jun 24, 2016 at 3:10 PM 'Mihai B' via golang-nuts < golang-nuts@googlegroups.com> wrote: > I'm de

[go-nuts] Interface{} constrains on specific types

I'm developing a json schema generator (json schema from Go ast and the other way around). There is a keyword "oneOf" which requires exactly one schema to be valid in this keyword's value. In Go I translate it by using an empty interface{}. The issue is that when I convert the interface{} to