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

[Alex.Potanin at ecs.vuw.ac.nz]

Hello,

I must have missed the discussion before, but I am just wondering - why
inheritance? Why not have delegation or other composition mechanisms and
omit it entirely?

Thanks,
Alex.

> 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 hap!
>  pen.
>
> 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
>
>
>
>
> _______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core
>