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) ).
--John
