[Grace-core] Inheritance and object initialisation

[Lex Spoon]

I am way outside the thick of this design discussion, but I can
contribute a little Scala lore in case it helps.

On Mon, Jul 16, 2012 at 4:52 PM, Kim Bruce <kim at cs.pomona.edu> wrote:
> I think it's important to give the answers to these along principled lines rather than an
> ad hoc way.  I can give a complete formal semantics for classes and
> objects (which will likely be more accurate than my working through
> these examples one by one), if everyone agrees with my interpretation
> of objects as instantiations of anonymous classes and that these
> anonymous classes are the ones that are actually inherited from.

This is essentially how Scala approaches singleton objects, in case
there is any doubt.


> Given the ambiguities that Michael has illustrated, I don't know if we
> want to reconsider allowing inheritance from objects (though I understand
> that Andrew feels strongly about this).  I wish I knew more why Scala
> prohibits inheritance from objects!

There is a complex of technical issues here.

One issue is that Scala has separate namespaces for values and types.
Inheritance is from types. Thus, if one writes "object X extends foo",
the compiler looks up "foo" in the types namespace. As such,
inheriting from objects is not so much forbidden, as not possible to
express.

Now, every Scala object has an associated type. If "foo" is an object,
then "foo.type" is a singleton type for foo, so one might try having
the language support a definition like "object X extends foo.type".
However, now we have inheritance from a singleton type. Depending on
how that is interpreted, either (1) singleton types would have more
than one value in them, or (2) inheritance would not always mean
subtyping. Problem (1) is an issue for path-dependent types; (2) might
be tolerable in some cases, but would seem kinda weird.

These technical issues aside, it would be convenient to have some form
of inheritance from objects. It's been discussed, and I can describe
one of the ways to implement it without disturbing the rest of the
language: add a new syntax for referring to the anonymous class that
backs an object. For example, maybe programmers could write "object X
extends foo.class". Going this route, the core language stays the
same, and the programmer just gets some syntactic sugar for a kind of
inheritance that is not natively supported. Whether it's worth it is a
balancing act of features versus language bloat.


> I intend to play around a bit more with understanding inheritance from the
> viewpoint of interpreting classes as abbreviations of nested objects (as we
> have been to this point).

It's an intriguing point of view. I saw this sort of thing go by in a
few emails, but I confess I haven't had time to sit down and really
think about how it works. If you or anyone writes up a description
about how this kind of inheritance works, I'd be very interested in
reading it.

Lex