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

Reply via email to