I struggle with the same in any large project. You have to hope they documented
the api very well.
Needless to say I’m not a fan of “duck typing”. It makes a few things easier
and a lot of important things much harder.
> On Sep 22, 2022, at 5:27 PM, Rory Campbell-Lange <r...@campbell-lange.net>
> wrote:
>
> This email follows my email yesterday "cannot convert fs.FS zip file to
> io.ReadSeeker (missing Seek)". Thanks very much to those who replied and
> provided solutions.
>
> Following that, I'm interested to learn how people negotiate interface
> interchangeability in their programmes as my query above showed a basic
> misunderstanding of how that operates and how to approach the topic in
> general.
>
> At a basic level my assumption that an fs.File would be "file like" and
> therefore act like a file was upended by the need for a PDF importer library
> to require an *io.ReadSeeker. This assumption broke for an fs.File from a zip
> archive since that doesn't support seeking. That is logical but was hard to
> find out. Although I can easily jump to methods and see related docs using
> vim-go, I still find interface interpolation (if that is a reasonable term)
> difficult to understand.
>
> At a more abstract level, the concept of interfaces was a key attraction to
> me of go, next to goroutines. They not only promise loose coupling of
> independently developed pieces, but also allow functionality to be easily
> re-used through types sharing method signatures, not to mention interface
> embedding. But, perhaps because of my background in python and SQL, I find
> this abstraction tricky to grasp. It's difficult to know, offhand, what
> interfaces are best to implement in a particular case. That difficulty is
> compounded when one interface can be interpolated (in some cases only,
> depending on the underlying concrete type) to another interface. The set of
> possible interface "contracts" offered to an fs.File, for example, could
> approach a very large number (ignoring interface{}) depending on the
> underlying concrete type.
>
> The https://jordanorelli.com/post/32665860244/how-to-use-interfaces-in-go
> article (pointed to by "Go by Example") by Jordan Orelli uses the example of
> "...the Animal type will be an interface, and we’ll define an Animal as being
> anything that can speak". He writes:
>
> We start by defining our Animal interface:
>
> type Animal interface {
> Speak() string
> }
>
> I suppose my question is (and forgive me if this is a terrifically naive),
> how can one negotiate the go landscape of commonly used modules to
> re-utilise, where possible, a more commonly named interface implementing
> "Speak()" or convertible to provide "Speak()"?
>
> Finally I was surprised that I did not get a compile-time error when trying
> to convert an fs.File to a io.ReadSeeker for the (possible) case when an
> underlying concrete type did not support Seek.
>
> Many thanks,
> Rory
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/YyzhV8S8WgH7mrJK%40campbell-lange.net.
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/32577E73-FF07-4475-91B4-F18D7CFA6D01%40ix.netcom.com.
