On Thu, Sep 22, 2022 at 4: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:
>
I think one of the problems in this particular example is that it is for
some reason easy for people to accept Animal type to be something that can
speak. I can see that it is simply an example to show the mechanics of
interfaces, but it also sets the expectation that the interface name means
more than what it actually is: in Go, an interface is simply a method set.
This is a difficult concept for people coming from other languages. So you
can have:
if speaker, yes:=someInterfaceValue.(interface{Speak() string}); yes {
spearer.Speak()
}
without having a named interface at all.
That is one of the properties of duck-typing I enjoy, especially after
working with Java for many years. In Java, an interface is a contract. In
Go, an interface is just a method set, which can be used as a contract.
> 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/CAMV2RqoyphWeq63YBx%2B%2BYr%2B7Jn1K3zUc5n3P3%2Ba742DX7D39jQ%40mail.gmail.com.
