Hello,<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yeah, because it&#39;ll be compiled into a class rather than an interface, so DomNode couldn&#39;t inherit from that.  So after more thought, I&#39;ve come up with this patch which adds IDomEventTarget interface.<br></blockquote>
<div><br></div><div>What I did was to add the events directly to the DomNode, so it is possible to add the event listeners directly into the DomNode:</div><div><br></div><div>myNode.AddEventListener (...)</div><div><br></div>
<div>The problem with introducing C# interfaces into the mix is that it would be half a solution, they are not universally supported for incoming/outgoing arguments nor marshalling.</div><div><br></div><div>The second problem is that if you feed an IFoo to a class that expects and NSObject, there is no way other than checking at invocation time that you have an NSObject, and we do not really have any way of enforcing that the [Exports] are on the proper methods.</div>
<div><br></div><div>We do want to come up with a solution to this general problem, in general by adding Objective-C-like protocols to C#, where methods in a protocol can be made *optional* and must be implemented by an NSObject, but that is a longer term change that wont happen any time soon.</div>
<div> </div><div>For now, we will just flatten out objects that explicitly implement an interface, like in this case</div><div><br></div><div>Miguel</div></div>