Interface Upgrades in Go

Post by dead10ck » Mon, Dec 08, 2014, 9:12 PM UTC

crypto5 wrote: post #38

dead10ck wrote: post #37

Earlier quoted context omitted.

Another example of "Wtf were they thinking when they wrote this?" in the Java stdlib is MessageDigest. To build a digester object, you must pass it a string literal to tell it which algorithm to use, and catch a NoSuchAlgorithm exception. Instead of, you know, just using an enum for all supported algorithms.

I think standard Java library API doesn't know what algorithms are supported on particular platform, additionally you can implement your own messagedigest.

Post by Goopplesoft » Tue, Dec 09, 2014, 2:21 AM UTC

psherman wrote: post #21

Goopplesoft wrote: post #15

Earlier quoted context omitted.

It seemed to me that interfaces have a second function of providing partial uniformity across types (not just abstracting procedures). I.e the Animal interface has a method `Speak() string` and you have a function that takes an Animal that prints something like "Animal type {species} says {speak}" you would have to define a getter on the Animal's species even though its not a really a procedure. But I see what you me…

If you have a function that requires both the species and a speak message from an animal, it would make sense for the interface to have a function that returns both the species and speak strings. I think that this [0] does what you would want. If you want to guarantee that two structs contain a set of the same required fields, I believe the best practice would be to include an anonymous field for a struct with the fi…