For example, the HtmlString interface could require only "toString" as a method, but not everything that has that method should be considered that type.
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.
Although, there was a question/discussion similar to this here: https://www.youtube.com/watch?v=u-kkf76TDHE#t=2584
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.No, it isn't.
https://github.com/kuujo/yuppy/blob/master/yuppy/core.py
https://github.com/kuujo/yuppy/blob/master/tests.py
What you say is kind of funny, although rather an obvious sort of caustic witticism. But I think the answer is in fact obvious to you.
Are you saying it's obvious to you? That's great, but it's not obvious to me.
[1]: http://docs.zope.org/zope.interface/ [2]: http://twistedmatrix.com/documents/14.0.0/core/howto/compone...