Hi Carl,

On 02/19/2013 02:03 PM, Carl Franks wrote:
S32/Temporal says a DateTime object can be maniplated like so:
     $dt.delta(44, minutes);

Rakudo's core/Temporal.pm contains this:

     my enum TimeUnit (
         :second(1), :seconds(2),
         :minute(3), :minutes(4),
         [snip]
     );

which is used in the signature of both DateTime and Date's delta methods:
     method delta($amount, TimeUnit $unit) {
which I think means delta() can't be called outside of the scope of
the Temporal.pm file.

TimeUnit is accessible outside of this file, because it is part of the setting, and the setting forms the outer lexical scope for all user-space programs.

If I try running the synopsis example, I get the following error:
     Undeclared routine: minutes used at line 1

Works fine here:

mlenz@mlenz-workstation:~/p6/rakudo$ ./perl6 -e 'say ~DateTime.now.delta(4, hours)'
2013-02-19T18:20:34Z

The test files
S32-temporal/Date.t and
S32-temporal/DateTime.t
both die on the delta tests.

They work fine here. The only explanation that I can find for this discrepancy between our systems is that your build of Rakudo might be too old.

What version of Rakudo are you using? (try running perl6 --version)

Rather than export those 14 keys into the global namespace, would it
make more sense for the spec to be something more like this:
     $dt.delta( :minute(44) );
using the same argument conventions as DateTime.new() ?

I belive Carl Mäsak is better qualified to answer this question, since he changed the specs (there used to be a .truncated-to( :minutes ) or so), but here are two interesting points:

1) while every user-facing program does see those constants, they can easily redefined in any inner scope, so namespace pollution isn't too much of a problem

2) Adding deltas of time onto a given point of time is not commutative. For example First adding a month and then a day can be give you a different result than first adding a day and then a month. But named arguments are unordered by nature, which makes them a poor fit for non-commutative operations.

Cheers,
Moritz

Reply via email to