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

[Marco Servetto]

The short cynic answer:
Grace want mainly to teach features present in Java/C#/C++/python.
This means that it have to be at least as bad as the union of them all :P

For the best of my understanding, the only really complex point in the
programming language design space that Grace do not have but all of
Java/C#/C++ have is type based method overloading.

Oh, yes, and there is only one supported numeric type, so no need for
conversion/cohertions here, ... however they are thinking to change it
and allow stuff like
1+Complex(1,3) happen.... thus pushing the conversion/cohertions mess
too inside grace.

On 10 December 2014 at 13:50,  <Alex.Potanin at ecs.vuw.ac.nz> wrote:
> 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
>>
>
> _______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core