I'm no expert, but here's my take:
On Thu, Mar 31, 2005 at 01:11:37PM -0500, Aaron Sherman wrote:
> 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?
I don't quite know what you mean by "type massaging choices", but sure
the compiler *can* issue errors on signature mismatch. When you say
my X $a;
the compiler has to treat $a like an X even if it doesn't know
everything there is to know about X (X may not even be defined yet).
So if you pass $a to a routine that's expecting a Y, then the compiler
can and will carp.
If, by "type massaging choices" you mean deciding whether or not to
accept a variable in a signature slot based on its type (i.e., if the
parameter is declared as a super-type of X, do we accept a X for this
parameter), then I think the compiler can do that as well.
> 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).
final classes can not be derived from, non-final can.
closed classes can not have new methods added to them later on, open
classes can.
> 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)?
If I assume you're talking about "closed classes" here (as it seems),
then I'd say that you can not "redefine the interface" or change it's
internals.
If you really do mean "finalized classes", then I'd think that you *can*
change the interface or the internals.
> Next, what are the conditions under which a class can be finalized?
>
> * Can we finalize a class which has non-finalized ancestors?
Certainly. Even if you meant "can we close a class which has
non-closed ancestors", I think you can do both. Not sure though.
> * What if it has method parameters/return values or member
> variables whose types are not finalized?
Finalization and closing is not something you do to instances, but
rather classes.
> * What if it applies roles which are not finalized?
I don't think you can finalize roles (it doesn't make sense to me to
be able to do so anyway) Closing roles, I think you can do though.
Also, according to
http://dev.perl.org/perl6/synopsis/S12.html#Open_vs_Closed_Classes
There is no syntax for declaring individual classes closed or
final. The application may only request that the optimizer close
and finalize unmarked classes.
So you would have a default policy of closed/final and then
open/unfinalize individual classes, or have a default policy of
open/non-final and have no way to close/finalize individual classes.
> Another question: how does finalization interact with a class's
> metaclass?
I don't think it does, except that that may be the hook by which we
obtain "no dreviatives allowed" on implementation. (i.e. the
meta-classes enforces the restrictions placed upon the class)
> 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?
You've strayed beyond my idea-space here :-)
> > 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?
Sure.
> Will core types be finalized by default?
No. It would be very un-perl-like to have such an unasked for
restriction IMHO.
Caveat lector, I'm not of the cabal.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
