On Wed, Aug 28, 2002 at 12:17:55PM -0400, Dan Sugalski wrote:
> At 10:36 AM +0200 8/28/02, [EMAIL PROTECTED] wrote:
> > >> Will there be automatic calling of the deserialization method
> >>> for objects, so that code like this DWIMs...
> >
> >>> my Date $bday = 'June 25, 2002';
> >
> >> Err... what do you mean it to do?
> >
> >Wow, this is nice. He means (I think) that this will be translated into
> >
> >my Date $bday = Date->new('June 25, 2002');
>
> That's really unlikely. More likely what'll happen is:
>
> my Date $bday;
> $bday = 'June 25, 2002';
>
> and it'll be up to $bday's string assignment code to decide what to
> do when handed a string that looks like a date.
op wise, how is that different from the original suggestion of
my Date $bday = 'June 25, 2002';
?
> That should work OK for a variety of reasons. $bday is strongly typed
> since you told perl what type it was in the my declaration. Date can
> also override string assignment, thus Doing The Right Thing (pitching
> a fit or taking a date) when you assign to it.
>
> I can see downsides to it, though--it means you lose the compile-time
> type checking, since just because we're getting the wrong type
> doesn't mean it's really an error. OTOH it's not like we have strong
> compile-time type checking now...
If the compiler were able to see that my Date $bday = 'June 25, 2002';
is one statement that both types $bday as Date, and then assigns a constant
to it, is it possible to do the conversion of that constant to a constant
$bday object at compile time? (and hence get compile time checking)
Without affecting general run time behaviour.
Nicholas Clark
