[Grace-core] Inheritance: what is it meant to be good for?

Kim Bruce kim at cs.pomona.edu
Tue Dec 9 22:36:26 PST 2014


I thought it might be best to specify my minimum needs for inheritance, leaving room for adding new things if there are good reasons.

1.  We need single inheritance on classes and on immutable objects, when we have access to the compete definitions of the super-class/super-object.  I.e., at the point of definition, we have complete knowledge of all features of the superclass/object, including confidential features.  This allows us to know when we are overriding existing features and (very importantly) knowing when we might be (illegally) overloading features.

It is handy to be able to inherit from newly formed objects so that we can get the initialization right, but it is not part of the minimal needs for inheritance in my view.

2.  When inheriting we can add new features (defs, vars, and methods) as well as override existing methods.  I'm less sure about overriding an existing (confidential) def or var by a method.  (Public defs and vars are already represented by methods, so they are fine.)  Overriding other features makes me nervous, but perhaps unnecessarily.

3.  Initialization of objects formed using inheritance (actually all are, since all inherit from top object):  First the complete object is laid out, with slots for defs, vars, and methods, both inherited and newly defined.  Methods are then associated with their slots -- those defined in the object/class can be inserted directly.  Any not overridden can be inserted from the parent.  Then the initialization code from the superclass/object is run, followed by the initialization code from the object being defined.  The initialization code shall be run with the object being defined as the value of self.  Thus if initialization code (even in the superclass) executes a method that has been overridden then the new version will be executed.  This of course raises the possibility that a new method called from the superclass initialization code might access a def or var that has not yet been initialized, but I consider that the programmers responsibility to make sure that doesn't happen.

Subclasses/object may invoke superclass methods by super.m(...).  This just allows the invocation of such methods in a context where self is the (sub)object being defined.

The above is necessary in order to build the kind of frameworks that i need for my graphics system, where students update fixed methods that are pre-wired to respond to events.

4.  I would like the static type system to be able to constrain inheritance so that overriding one method is guaranteed not to break another (inherited) method in the same class.  At the moment, I'm not sure what, if any, constraints that puts on the dynamically typed system.

5.  Finally, inheritance should look familiar to those used to Java, C++, Scala, etc.  This is necessary both to convince instructors to use it, but also to make it easier to transition from Grace to one of those languages.  Of course they are inconsistent with each other (e.g., with initialization), but I'm sure you get my drift ...

I'm sure I'm leaving some stuff out here, but let's take this as the start of the conversation.  Questions??  Comments?

[There are likely other things that I can be convinced should be part of inheritance, but I've just tried laying out the minimum I need in order to teach my intro course(s).]


Kim






More information about the Grace-core mailing list