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