<p>Am 06.09.2017 10:34 schrieb "Ryan Joseph" <<a href="mailto:ryan@thealchemistguild.com">ryan@thealchemistguild.com</a>>:<br>
><br>
><br>
> > On Sep 6, 2017, at 2:50 PM, Graeme Geldenhuys <<a href="mailto:mailinglists@geldenhuys.co.uk">mailinglists@geldenhuys.co.uk</a>> wrote:<br>
> ><br>
> > There is NO need to make Hook public, because you can always get access to that functionality via the Supports() call and get a reference to IHook.<br>
><br>
> The Supports() call is the key takeaway here.<br>
><br>
> For the sake of discussion can you see why it makes sense that “hook.” syntax would be implied because the class does indeed supposedly implement the interface? Everything about the syntax says that the methods in IHook should be in TBaseClass so I can’t help but feel like it was an omission or not fully finished. It would be messy to implement probably because you would risk a number of name collisions with existing methods.</p>
<p>No it's definitely by design. If you use alias clauses ("procedure IMyIntf.Foobar = Blubb") then you also won't have the interface's method in your class, but only the alias. The method can only be accesssed by the interface's method name by using an interface instance not the class instance. The "implements" clause is just an advanced variant of that in that it allows you to use a complete class (though you're still able to implement selected methods of the interface in the base class which aren't delegated then).</p>
<p>Regards,<br>
Sven</p>