[Grace-core] Abstract methods/classes

Kim Bruce kim at cs.pomona.edu
Wed Jun 4 08:49:54 PDT 2014


The main thing is we need to get it into the implementation in such a way that a static checker could ensure that we don't create anything that still has an abstract method (other checkers could be more liberal, but I want to be able to write a strict one).  Either annotation or body would be fine, but either way, the type needs to be compatible with everything.

Perhaps we can add it to our list of things to put in this summer.

Kim



On Jun 4, 2014, at 3:15 AM, Timothy Jones <tim at ecs.vuw.ac.nz> wrote:

> On 04/06, James Noble wrote:
>> On 4/06/2014, at 13:34 pm, Kim Bruce <kim at cs.pomona.edu> wrote:
>> 
>>> We still need to figure out abstract methods. 
>> 
>> but I found an old Nov 2013 email saying we'd agreed on 
>> 
>> method foo {abstract}
>> 
>> and minutes from Feb 2014 saying the same thing.
>> This is basically Smalltalk's "subclassResponsibilty" message. Running it raises an error.
>> 
>> There's an earlier email of mine proposing 
>> 
>> method foo is abstract {}
>> 
>> using an annotation allows a class to be abstract while still having some concrete features 
>> but there may be issues having the same annotation for both classes and methods
>> or teaching people about annotations before abstract classes.
>> 
>> for me I still lean towards an annotation but I'm not sure why.
>> Michael / Tim - any particular preferences? 
> 
> I'm leaning back to the annotation approach, where it just bans you from calling
> it directly, but allows you to call it through super or inherit from it. That
> way it works for both methods and class methods.
> 
> -- 
> Tim




More information about the Grace-core mailing list