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 <[EMAIL PROTECTED]> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback