TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
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.
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.
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.
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'.
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
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
My intention is to always specify things such that M can be compiled,
with introspection information available (e.g. you can use