<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Andrew P Black</div><div><br>On 4 Jun 2014, at 03:15, Timothy Jones <<a href="mailto:tim@ecs.vuw.ac.nz">tim@ecs.vuw.ac.nz</a>> wrote:<br><br></div><blockquote type="cite"><span>I'm leaning back to the annotation approach, where it just bans you from calling</span><br><span>it directly, but allows you to call it through super or inherit from it. That</span><br><span>way it works for both methods and class methods.</span></blockquote><br><div>I don't think that I understand this remark. What does "calling it directly" mean? Requesting an abstract method on self? Being able to write such a request is the while reason for having abstract methods.</div><div><br></div><div>In the dynamic semantics, an abstract method <i>is not there</i> — and requesting it will give a "method does not exist" error. Because the method is not there, I would prefer an annotation (perhaps <b>is required</b> rather than <b>is abstract</b>) to a body. </div><div><br></div><div>In the same meeting that James referred to, we also disused an "is complete" annotation on an object that invites a checker to check that an object actually defines all of the methods that it self-requests. We should not make that test the default, because it will upset the people who like to do dynamic programming. </div><div><br></div><div> Andrew</div><div><br></div><div> </div></body></html>