7 ms·

I like the histogram showing how much more frequent interfaces with just one or two methods are. How frequent are problems where classes unintentionally use an

I like the histogram showing how much more frequent interfaces with just one or two methods are. How frequent are problems where classes unintentionally use an interface due to identical signatures? Seems likely to happen in theory if so many interfaces have few functions.

mjr00 7y ago
In theory, yeah... in practice, as someone who uses Go and Python with mypy (which supports structural type-checking using the Protocol interface) professionally, I haven't seen it happen. It's easy to think of contrived examples like the one in the post, where Cat/Dog/Table all implement GetLegCount(), but in practice your interface methods usually aren't that simple, and interface signatures like func InsertFoo(*sqlx.DB, Foo) (int64, error) are very unlikely to be unintentionally implemented.
- mrkeen 7y ago
  I tend to use nominal types a lot in other languages, so I have a lot of types with id() or value(). Would those be mixed up?
  - masklinn 7y ago
    If the interfaces have only id/value with matching parameters and return types then yes the interfaces would be functionally identical and all objects satisfying one of the interfaces would satisfy the others.
  - morelisp 7y ago
    They would be, but it's also unlikely you would be able to write something useful using only the id and value such that you might confuse something. There's some "self-limiting" - the smaller the interface, the more likely you get accidental implementation, but also the less likely you are to confuse them in a way that typechecks but actually does something unexpected. A practical example might be io.Closer - I am certain I implemented this in a dozen types I never intend to pass to any io functions. But no io functions actually take just a Closer, and if I did write some generic cleanup routine that only requires a Closer, it's probably fine and maybe even good if it works on byte IO and gRPC connections and Kafka streams. (Especially without generics, it might be the best I can do.)
  - deleted 7y ago
    [deleted]
  - zaphar 7y ago
    In practice if your 'id() string' method returns an id as a string for the object doesn't it do what you need it to? So you actually need to care whether the intended to satisfy your contract or not? You might care if you expect the Id string to look a particular way. But then you probably wanted to use a type other than string for the return type.
    - mrkeen 7y ago
      > you probably wanted to use a type other than string for the return type. That's the point. In order for (String userId) to not be confused with (String password), I wrap them with nominal types UserId and Password. If the language looks at both UserId and Password and decides they're interchangeable because they both satisfy the contract 'contain a String', then that completely negates the point.
- Nullabillity 7y ago
  And at that point, you have.. nominal types with less documentation?
jerf 7y ago
I've been programming for over 20 years primarily in languages in which this can nominally happen, and I think I've literally never seen it happen. I've been in situations where I expected a method and it was missing (e.g., Python code expecting a vaguely-file-like object to have seek, receives a socket), but that's the closest to this sort of thing I think I can say I've come. I've never had a case where I called a method that I expected to be one sort of thing, and got a method that was actually a completely different thing. I used to worry about this sort of thing, but now I think that any language designer making a new language should just consider it a non-issue. If you happen to make it impossible for some other reason, sure, cool, I guess, but don't put even a little bit of effort into worrying about this case. (Note I'm not saying it can't happen, or even be bad if it did. I'm sure it's happened to some people, and of that set, I'm sure there must be at least one person with a story of how it went really badly wrong somehow. I'm just saying that compared to the sorts of issues that affect every programmer in your language every day, worrying about this edge case is not productive. If this is your biggest problem in your language, or even fits into the top 100, please let me know about your surprisingly perfect language as I am very interested in using it.)
- throwaway894345 7y ago
  My experience is the same. It's interesting to me that people are very concerned about Go's structural subtyping, but they generally have no qualms about passing functions around. Given that the contract for a function is the function signature, and the contract for an interface is [all function signatures and their associated names], surely the latter is less error prone?
  - lmm 7y ago
    A function explicitly has no further semantics than its inputs and outputs. The receiving function shouldn't, and won't, assume anything about what the function it's passed does. Whereas when you're passed a bundle of named functions that (presumably) share state between them, it's very natural to assume that this implies relationships between how those functions will behave (even in the simplest examples, e.g. Java's Iterator has only two methods, but it also specifies a relationship between what those two methods return). And so it's very easy to write code that relies on those relationships, and then breaks when passed a bundle of named functions that does not conform to that relationship.
seertaak 7y ago
I think it's really interesting to contrast this with Stroustroup's advice on concepts: "My rule of thumb is to avoid “single property concepts.”". He gives an excellent example leading to this dictum: single property interface "Drawable". Let Shape implement drawable with widely expected results. But: let Cowboy implement Drawable -- now with disastrous consequences. The solution to this dilemma is as stated above, not to allow concepts/interfaces/{wave hands} to refer to a single object -- for example, a number is a concept which refers to multiple operations (i.e. methods). To my mind, this feels right, albeit initially surprising. It makes me think that e.g. the "Neg" interface in Rust is wrong. See: http://www.stroustrup.com/good_concepts.pdf http://www.stroustrup.com/good_concepts.pdf
- loopz 7y ago
  For golang, single method interfaces are recommended as preferable. The problem with huge interfaces or classes is they can always become larger! While if you compartmentalize single responsibility into separate components (may be several methods if applicable to the domain and design), each reason to change may be restricted to that bounded context only. If not, it's a signal design might need revisit. The problem with "Drawable" is that it is property/data, and not messaging-based, thus breaking encapsulation, even if it was behaviour-based.
  - seertaak 7y ago
    > The problem with huge interfaces or classes is they can always become larger! That's definitely a good reason to prefer small interfaces; I hadn't thought of that but it certainly makes sense. That said, I think we may be referring to different things when we use the word "property". Stroustroup is talking about properties in the mathematical sense, i.e. he's talking about the properties of the operation "draw()" in the concept Drawable. Am I misunderstanding you? To my mind that's an operation and closer to "message" (emphasis on the verb aspect) rather than data or property.
    - loopz 7y ago
      "Drawable" as a name is pretty bland, like patterns. Do we ever really say "drawable" out loud? So I suspect if we seek more meaningful objects and models, they become more active, have better names, improved design, etc. If you ask a janitor about Drawable, will he say it's all about draw()? So I think it's kind of a dreary default that we need to avoid and focus on who the actors are, what messages they will pass, and the hidden treasures they encapsulate (don't show, but tell!).
apta 7y ago
It has already caused several issues in golang, and this is an example: https://github.com/golang/go/issues/16474 https://github.com/golang/go/issues/16474
- masklinn 7y ago
  That’s a different issue. This is not just using structural interfaces but downcasting to even lower interfaces without warning. That is, the method lies about what it’s looking for.
  - deleted 7y ago
    [deleted]
  - apta 7y ago
    It will cause issues if a type implements the interface where it didn't mean to.
superlopuh 7y ago
Anecdotally, this happened to me today

mjr00 7y ago

In theory, yeah... in practice, as someone who uses Go and Python with mypy (which supports structural type-checking using the Protocol interface) professionally, I haven't seen it happen. It's easy to think of contrived examples like the one in the post, where Cat/Dog/Table all implement GetLegCount(), but in practice your interface methods usually aren't that simple, and interface signatures like func InsertFoo(*sqlx.DB, Foo) (int64, error) are very unlikely to be unintentionally implemented.

mrkeen 7y ago
I tend to use nominal types a lot in other languages, so I have a lot of types with id() or value(). Would those be mixed up?
- masklinn 7y ago
  If the interfaces have only id/value with matching parameters and return types then yes the interfaces would be functionally identical and all objects satisfying one of the interfaces would satisfy the others.
- morelisp 7y ago
  They would be, but it's also unlikely you would be able to write something useful using only the id and value such that you might confuse something. There's some "self-limiting" - the smaller the interface, the more likely you get accidental implementation, but also the less likely you are to confuse them in a way that typechecks but actually does something unexpected. A practical example might be io.Closer - I am certain I implemented this in a dozen types I never intend to pass to any io functions. But no io functions actually take just a Closer, and if I did write some generic cleanup routine that only requires a Closer, it's probably fine and maybe even good if it works on byte IO and gRPC connections and Kafka streams. (Especially without generics, it might be the best I can do.)
- deleted 7y ago
  [deleted]
- zaphar 7y ago
  In practice if your 'id() string' method returns an id as a string for the object doesn't it do what you need it to? So you actually need to care whether the intended to satisfy your contract or not? You might care if you expect the Id string to look a particular way. But then you probably wanted to use a type other than string for the return type.
  - mrkeen 7y ago
    > you probably wanted to use a type other than string for the return type. That's the point. In order for (String userId) to not be confused with (String password), I wrap them with nominal types UserId and Password. If the language looks at both UserId and Password and decides they're interchangeable because they both satisfy the contract 'contain a String', then that completely negates the point.
Nullabillity 7y ago
And at that point, you have.. nominal types with less documentation?

jerf 7y ago

I've been programming for over 20 years primarily in languages in which this can nominally happen, and I think I've literally never seen it happen. I've been in situations where I expected a method and it was missing (e.g., Python code expecting a vaguely-file-like object to have seek, receives a socket), but that's the closest to this sort of thing I think I can say I've come. I've never had a case where I called a method that I expected to be one sort of thing, and got a method that was actually a completely different thing. I used to worry about this sort of thing, but now I think that any language designer making a new language should just consider it a non-issue. If you happen to make it impossible for some other reason, sure, cool, I guess, but don't put even a little bit of effort into worrying about this case. (Note I'm not saying it can't happen, or even be bad if it did. I'm sure it's happened to some people, and of that set, I'm sure there must be at least one person with a story of how it went really badly wrong somehow. I'm just saying that compared to the sorts of issues that affect every programmer in your language every day, worrying about this edge case is not productive. If this is your biggest problem in your language, or even fits into the top 100, please let me know about your surprisingly perfect language as I am very interested in using it.)

throwaway894345 7y ago
My experience is the same. It's interesting to me that people are very concerned about Go's structural subtyping, but they generally have no qualms about passing functions around. Given that the contract for a function is the function signature, and the contract for an interface is [all function signatures and their associated names], surely the latter is less error prone?
- lmm 7y ago
  A function explicitly has no further semantics than its inputs and outputs. The receiving function shouldn't, and won't, assume anything about what the function it's passed does. Whereas when you're passed a bundle of named functions that (presumably) share state between them, it's very natural to assume that this implies relationships between how those functions will behave (even in the simplest examples, e.g. Java's Iterator has only two methods, but it also specifies a relationship between what those two methods return). And so it's very easy to write code that relies on those relationships, and then breaks when passed a bundle of named functions that does not conform to that relationship.

seertaak 7y ago

I think it's really interesting to contrast this with Stroustroup's advice on concepts: "My rule of thumb is to avoid “single property concepts.”". He gives an excellent example leading to this dictum: single property interface "Drawable". Let Shape implement drawable with widely expected results. But: let Cowboy implement Drawable -- now with disastrous consequences. The solution to this dilemma is as stated above, not to allow concepts/interfaces/{wave hands} to refer to a single object -- for example, a number is a concept which refers to multiple operations (i.e. methods). To my mind, this feels right, albeit initially surprising. It makes me think that e.g. the "Neg" interface in Rust is wrong. See: http://www.stroustrup.com/good_concepts.pdf http://www.stroustrup.com/good_concepts.pdf

loopz 7y ago
For golang, single method interfaces are recommended as preferable. The problem with huge interfaces or classes is they can always become larger! While if you compartmentalize single responsibility into separate components (may be several methods if applicable to the domain and design), each reason to change may be restricted to that bounded context only. If not, it's a signal design might need revisit. The problem with "Drawable" is that it is property/data, and not messaging-based, thus breaking encapsulation, even if it was behaviour-based.
- seertaak 7y ago
  > The problem with huge interfaces or classes is they can always become larger! That's definitely a good reason to prefer small interfaces; I hadn't thought of that but it certainly makes sense. That said, I think we may be referring to different things when we use the word "property". Stroustroup is talking about properties in the mathematical sense, i.e. he's talking about the properties of the operation "draw()" in the concept Drawable. Am I misunderstanding you? To my mind that's an operation and closer to "message" (emphasis on the verb aspect) rather than data or property.
  - loopz 7y ago
    "Drawable" as a name is pretty bland, like patterns. Do we ever really say "drawable" out loud? So I suspect if we seek more meaningful objects and models, they become more active, have better names, improved design, etc. If you ask a janitor about Drawable, will he say it's all about draw()? So I think it's kind of a dreary default that we need to avoid and focus on who the actors are, what messages they will pass, and the hidden treasures they encapsulate (don't show, but tell!).

apta 7y ago

It has already caused several issues in golang, and this is an example: https://github.com/golang/go/issues/16474 https://github.com/golang/go/issues/16474

masklinn 7y ago
That’s a different issue. This is not just using structural interfaces but downcasting to even lower interfaces without warning. That is, the method lies about what it’s looking for.
- deleted 7y ago
  [deleted]
- apta 7y ago
  It will cause issues if a type implements the interface where it didn't mean to.

superlopuh 7y ago

Anecdotally, this happened to me today