HaloO,
John M. Dlugosz wrote:
Larry, you've wanted to have class names used within a class be
virtual. With various degrees of conviction across the synopses, you've
wanted classes defined within a class to be overridable, or all classes
referenced by a class to be overridable, speculating on whether this is
do-able.
Let's consider the following code that is a mild rework of John's.
module M
{
class C
{
method mc {...}
}
class D
{
has C $.a; # implies method a is rw :( D: --> C )
method m :( --> C) # P::C in P::E?
{
my C $b = .new;
$b = $.a; # type error in E::m?
$b.mc; # OK for M::C, error for P::C
$b.pc; # OK for P::C, error for M::C
return $b;
}
}
}
package P
{
class C
{
method pc {...}
}
class E is D
{
# inherits M::D::a and M::D::m
}
}
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.
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'.
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?
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
