develooper Front page | perl.perl6.language | Postings from March 2005

Re: Parameter and trait questions - just how 'only' _is_'read-only'?

Thread Previous | Thread Next
From:
Aaron Sherman
Date:
March 31, 2005 10:11
Subject:
Re: Parameter and trait questions - just how 'only' _is_'read-only'?
Message ID:
1112292697.7453.19516.camel@pps
On Thu, 2005-03-31 at 11:51, Larry Wall wrote:

>     my X $a;
> 
> is *necessary* but not *sufficient* to do method existence testing in
> standard Perl 6 at compile time.  You can do it IFF you have the class
> information AND the classes are willing to cooperate in your scheme.
> In the current design, you can pragmatically request that all classes
> cooperate, and you will get the cooperation of all classes that haven't
> specifically been requested to be non-cooperative.  This is what all
> the mumbo-jumbo about open/closed and final/non-final classes comes
> down to.

So let me try to unpeel that (I'm not trying to be difficult, it's just
that this is a difficult topic as evidenced by the mountain of
documentation on the topic by languages that try to be only HALF as
flexible).

If you declare a variable to be of a type (let's even say a class to be
specific), then you have hinted to the compiler as to the nature of that
variable, but nothing is certain.

That is to say that the compiler cannot:

      * Make any type-massaging choices yet on (implicit or explicit)
        method invocations
      * Issue any errors based on signature miss-matches

Ok?

Now we move on to the idea of finalization. Please correct me where I
conflate finalization and openness. I'm not sure I understand the
difference at all (no, I'm certain I don't).

We assert (don't have the docs handy, but I'll just arm-wave the syntax)
that the class is now finalized. This means any attempt to re-define the
interface of the class is a compile-time error, correct? What about
changing the internals of the class (e.g. changing the code associated
with a method without re-defining the signature)?

Next, what are the conditions under which a class can be finalized?

      * Can we finalize a class which has non-finalized ancestors?
      * What if it has method parameters/return values or member
        variables whose types are not finalized?
      * What if it applies roles which are not finalized?

Obviously each one of these questions comes with a host of "what happens
if" questions given a "yes" answer....

Another question: how does finalization interact with a class's
metaclass? Does the metaclass become a const? Is the type of a metaclass
itself a finalized class? If not, can it be finalized by user code?

> One additional wrinkle is that *anyone* is allowed to declare a
> class non-cooperative (open or non-final) during *any* part of the
> compilation

... even after it is declared final?

Will core types be finalized by default?

> I hope this clears things up a little.

Clear.... that's a word ;-)

Yes, your message helped. I can sense your exasperation, but it is my
hope that asking stupid questions now means that we'll have smart
answers by the time P6 is released. If I'm overly slowing the process,
please say so, and I'll stop asking.

-- 
Aaron Sherman <ajs@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback



Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About