One of the best type features of Go is the lack of need to do something like this: "@implements(IEatable)". If a class implements all of the methods of the interface, then it automatically implements that interface. Yuppy seems like a step backwards in OO in this regard.
Is it possible to indicate, in an interface, that it's not a structural type? Ie, that classes need to specifically indicate they implement it to be considered it's type?
For example, the HtmlString interface could require only "toString" as a method, but not everything that has that method should be considered that type.
The idea would be, in this case, to create a method called "toHtmlString". The name "toString" suggests a generic String is created for the object, but HtmlString represents a specially formatted String.
Rather than having a class implement HtmlString as a way to specify that its "toString" method works differently to the usual or expected way for a method of that signature, you can instead write a "toHtmlString" which is more clear. Reading code as "myObject.toString()" vs "myObject.toHtmlString()" is better than having to check the class signature for a special contract pertaining to general-looking method names.
The gist was that, if the interface and the structs that are supposed to satisfy that interface belong to the same package, and then you want to prevent any outsider from implementing that interface, you can actually include an unexported method:
type HtmlStringer interface {
ToString() string
isHtmlStringer()
}
Since it is unexported, no outsider struct can actually satisfy this interface anymore.
Perhaps this is an unpopular opinion, but I think the Duck typing philosophy of Python is a feature, not a bug. Imposing the verbosity and rigidity of Java-style OO onto Python seems like a step backwards to me.
I feel like one of the merits of python is the looseness of classes and multiple inheritance. You get the benefits of OO without some of the pitfalls. Sure, you can go through the effort of defining an abstract class but it often isn't needed since your object is often composed of a bunch of separate objects - dealing with a formal contract to some 'abstract' version of your object just adds boilerplate and ends up creating convoluted class hierarchies.
Honestly, it's still hard for me to tell, and those two files don't make it clearer. It's got tests, which is good and presumably counts for the serious case, but I've seen similarly excessive testing done for obvious jokes (like the enterprise Java FizzBuzz parody).
Are you saying it's obvious to you? That's great, but it's not obvious to me.
I don't know, there seems something unpleasantly supercilious about taking a software project that's obviously written to a high standard and saying you think it's a joke. How do you know the author won't be unhappy to see someone say that? It kind of seems like classic #shithnsays.
This is very reminiscent of zope.interface used in Twisted. I wouldn't want to argue for or against it, but I've had times when something like this might have been useful in large code bases.
It would be very helpful to add to the README a section explaining what problems this solves. So examples of conventional python classes exhibiting weaknesses that are improved by using yuppy features.
But either way, you're going to get a runtime error. Languages like Java or C# that actually have real interfaces and abstract classes can detect these problems at compile time. This seems only marginally better.