On Wed, 28 Aug 2002, David Wheeler wrote:
: I have to agree with this. Ideally, IMO, there'd be some magic going on
: behind the scenes (maybe with a pragma?) that automatically typed
: variables so we wouldn't have to be so redundant, the code would look
: more like (most) Perl 5 OO stuff, and I'd save my tendonitis. What I
: mean (ignoring for the moment the even simpler syntax suggested earlier
: in this thread) is this:
:
: my $date = Date.new('June 25, 2002');
:
: Would automatically type C<$date> as a Date object.
Assignment is wrong for conferring compile-time properties, I think.
Maybe something more like:
my Date $date is new('June 25, 2002');
except that this implies the constructor args would be evaluated at
compile time. We need to suppress that somehow. 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. 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' };
though "first" might be too early. The init should be inline with
the declaration, so maybe it's
my Date $date is now { .init 'June 25, 2002' };
That might be so common that we could make syntactic sugar for it:
my Date $date { .init 'June 25, 2002' };
That's evaluating the closure for a side effect. Or we could evaluate
it for its return value, factoring the init out into the implementation
of "now", and just get:
my Date $date { 'June 25, 2002' };
Either way, this makes data declarations more like sub declarations
in syntax, though the semantics of what you do with the final closure
when are obviously different. That is, for ordinary data a bare {...}
is equivalent to "is now", while for a subroutine definition it's more
like "is on_demand".
Whatever. My coffee stream hasn't yet suppressed my stream of consciousness.
Larry
