Larry wrote:
> : my $date = Date.new('June 25, 2002');
>
> Assignment is wrong for conferring compile-time properties, I think.
Agreed. For a start, it's too late. The declaration is compile-time;
the assignment, run-time.
> We almost need some kind of topicalization:
>
> my Date $date = .new('June 25, 2002');
>
> but I think that's taking topicalization a bit too far.
Agreed.
> The ordinary
> way to suppress early evaluation is by defining a closure. I've argued
> before for something like a topicalized closure property:
>
> my Date $date is first { .init 'June 25, 2002' };
Can I just point out that is is much longer and funkier than:
my Date $date = Date.new('June 25, 2002');
> my Date $date is now { .init 'June 25, 2002' };
As is that.
> That might be so common that we could make syntactic sugar for it:
>
> my Date $date { .init 'June 25, 2002' };
Urk. I'm having flashbacks to C++. Please, no!
> my Date $date { 'June 25, 2002' };
Arrrrrgggghhhhhhh!!!!!
> Either way, this makes data declarations more like sub declarations
> in syntax,
Yes. That's precisely my problem with it. Syntactic diversity is *good*.
> Whatever. My coffee stream hasn't yet suppressed my stream of consciousness.
<grin>
I'd suggest that redundancy in syntax is often a good thing and
that there's nothing actually wrong with:
my Date $date = Date.new('June 25, 2002');
And, furthermore, that you could easily define special semantics
for void-context constructor calls via undef'd but typed variables,
so that you could just write:
(my Date $date).new('June 25, 2002');
and have the interpreter autovivify the object.
Damian
