title: Is there any advantage in disallowing interface implementation for existing classes?
body: <p>In static OOP languages, interfaces are used in order to declare that several classes share some logical property - they are disposable, they can be compared to an <code>int</code>, they can be serialized, etc.</p>
  
  <p>Let's say <code>.net</code> didn't have a standard <code>IDisposable</code> interface, and I've just came up with this beautiful idea:</p>
  
  <pre><code>interface IDiscardable { void Discard(); }
  </code></pre>
  
  <p>My app uses a lot of <code>System.Windows.Form</code>s, and I think that a <code>Form</code> satisfies the logical requirements for being an <code>IDiscardable</code>. The problem is, <code>Form</code> is defined outside of my project, so <code>C#</code> (and <code>Java</code>, <code>C++</code>...) won't allow me to implement <code>IDiscardable</code> for it. <code>C#</code> doesn't allow me to formally represent the fact that a <code>Form</code> can be <code>discarded</code> ( and I'll probably end up with a <code>MyForm</code> wrapper class or something. </p>
  
  <p>In contrast, <code>Haskell</code> has <code>typeclasses</code>, which are logically similar to interfaces. A <code>Show</code> instance can be presented (or <em>serialized</em>) as a string, <code>Eq</code> allows comparisons, etc. But there's one crucial difference: you can write a typeclass instance (which is similar to implementing an interface) without accessing the source code of a type. So if <code>Haskell</code> supplies me with some <code>Form</code> type, writing an <code>Discardable</code> instance for it is trivial.</p>
  
  <p>My question is: from a language designer perspective, is there any advantage to the first approach? <code>Haskell</code> is not an object oriented language - does the second approach violates <code>OOP</code> in any way?</p>
  
  <p>Thanks!</p>