FAQ
So it seems like you can stub out methods individually without having to
stub them all with what Paul suggested even on a single large interface. So
in this case I am still not sure what the individual interfaces serve?

Small interfaces are obviously idiomatic, but their utility I thought came
in when functions only needed to take 1 or 2, out of the say 15 you split
out. If some method would need 10 out of them, them it seems unwieldy.
Wrapping those 10 up in another interface doesn't make sense because they
have no concept together. For example there is a lot of interface
composition in the io package, but you wouldn't make a
RunePipeReadWriterMtimeGetterCloser or something like that right?

I am also extremely curious about the intent behind embedding an interface
in a struct, which I can find almost zero information on. Embedding a
struct in a struct and an interface in an interface make total sense but an
interface in a struct does compile so there must be a purpose? Anyone? This
is driving my curiosity wild!

For the background you're asking about, the Machine is the layer inbetween
different kinds of well, machines, that a single api will be built on top
of. Machines could be different os's or have different capabilities. That's
about all I can say on it, probably makes sense to have Machine be a
collection of components as things get larger, but this problem I am having
lies at the heart of that.

Thanks for the help!
On Friday, April 17, 2015 at 12:41:11 AM UTC-7, Egon wrote:
On Friday, 17 April 2015 09:04:55 UTC+3, jonathan...@gmail.com wrote:

Hey Egon, Yes those are the kinds of things in Machine, actions too like
ChangeRaid() or whatever. So this sounds like what Paul was suggesting but
how do the extra interfaces help? Could you guys point out some usages in
the standard lib maybe (or stdlib tests) which use interfaces embedded in
structs?
I don't know such examples in stdlib.

Maybe these help you out:
https://github.com/nwidger/nintengo/blob/master/nes/nes.go#L52
http://gobot.io/

They also use interfaces a lot and are similar in building "machines".

The extra interfaces help, by being able to stub them out: e.g.

type Machine struct {
CPU
RAM
}

func TestCPU() {
m := Machine{CPU: NewCPU(), RAM: ramStub{}}
// ...
}

func TestMem() {
m := Machine{CPU: cpuStub(), RAM: NewRAM()}
// ...
}

Also could you elaborate more on the context. I mean I have no clue what
it is supposed to do (https://github.com/golang/go/wiki/howtoask).
Essentially you know what you are talking about and it seems like I got the
gist of it, but really I don't. (See Barnum effect)

Essentially... who will use the thing you build, where will it be used,
how is it valuable to the end user etc.

+ Egon
--
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

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 8 of 9 | next ›
Discussion Overview
groupgolang-nuts @
categoriesgo
postedApr 17, '15 at 1:15a
activeApr 17, '15 at 7:05p
posts9
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase