TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:

The point I want to make is that we cannot think of P::C and M::C as
unrelated! There are the following typical uses of C in D:

  1) as the type of the attribute $.a
  2) as return type of m
  3) as type of the local variable $b

Within the body of m I've placed three uses of $b that I think
reveal the type aspect of C in assignment compatibility and in
availability of methods. The only way out I see is that there is
a cross-check of P::C with M::C at CHECK time. Note that the Frog
example in A12 has an inheritance relation between the outer and
the inner classes.

I agree, the issues with ② changing but ① not changing in E is mitigated if the new C is a subclass of the old C. I believe that extending hierarchies in parallel was Larry's germ.

For the record: I don't like the concept of C being virtual in the
same sense as methods are virtual. I think more along the lines of
parametric polymorphism. So D implicitly is 'class D [::C = OUTER::C]'.
This ::C is bound to P::C in 'class E is D'.
Attributes are frozen into the base class and don't override the way members do. That is why virtual class names don't apply to them.

If you wanted to define D as generic, you could do that too! In fact, if we had a pseudo-package that meant "ignore the current meaning of C and find the C that would be found if this one didn't exist" that was not bound at compile time, then you could get the same effect by using the default argument to D all the time and not worrying about it being generic.

I think this is what you are getting at. Maybe it could just work that way? There are subtle differences; Since D[C1] is a different type than D[C2] it means that E would not be a subclass of D, and in fact D would vary depending on what was in scope every time it is used not just when it is used as a base class!

Since subtyping will not be tied to subclassing like C++, Java, etc. then maybe that is not a problem, and maybe the concept (virtual class names) needs to be rethought in light of these other developments.

Side question: how binary can M be when compiling P? In C++ e.g. the
template code of D has to be available. Are there interface files in
Perl 6?

My intention is to always specify things such that M can be compiled, with introspection information available (e.g. you can use M::($variable) ).

Reply via email to