I recommend not to open this up for 6.0.0 core. Calendar conversion
is easy to do in a module, and the Date class has an absolute day
count, which is really all you need everything for an intermediate
representation. It wouldn't be hard to port Calendrica, for
instance.
Also, the difference bet
On Wed, Apr 21, 2010 at 12:35:11PM -0300, Daniel Ruoso wrote:
> Em Qua, 2010-04-21 às 00:16 -0700, Stefan O'Rear escreveu:
> > Normally, when you write a method call, the definition of the method is
> > entirely in the domain of the receiver's class:
> > $object.make-me-a-sandwich; # $object g
I whole-heartedly agree that we need to make a system independent of any
sort of time measurement system. I think the conclusion reached on IRC
was that most of the world uses or is at least familiar with the
Gregorian system.
Now, I can't help but think how we would define an Instant. The bes
Em Qua, 2010-04-21 às 00:16 -0700, Stefan O'Rear escreveu:
> Normally, when you write a method call, the definition of the method is
> entirely in the domain of the receiver's class:
> $object.make-me-a-sandwich; # $object gets to decide what this means
Actually, this is delegated to the disp
That's lifetime of the object, which is still monkeytyping, just on a less
global level than modifying the class directly.
Compare the Ruby example to this: (syntax is entirely made up):
my $foo = SomeClass.new;
{
methodical bar(SomeClass) { say "Hello, world!" }
$foo.bar # "Hello, worl
Ruby has a similar functionality that lets you define methods on an instance
object. Really, its how class methods are specified, you just put the class
name as the name of the object. Here is an example:
a = Object.new
def a.foo
puts "foo and #{self}"
end
They will stay on the object as long
This idea strikes me as being extremely similar to C#'s extension
methods, a feature that I've found to be particularly beneficial in
many cases. The fact that these methodicals are lexically-scoped is
especially nice, and the fact that they can be applied post-hoc to
arbitrary data items that have
Ok, so no fixed epoch, and arithmetic on Dates operates in integral days.
Sold.
It would be handy to have some predefined constants for some common epochs,
like JD, MJD, JD, etc. Those don't necessarily need to be in core for
6.0.0, though. Maybe a separate Date::Epochs module? Examples:
con
Am 20.04.2010 16:59, schrieb Dave Rolsky:
On Fri, 16 Apr 2010, pugs-comm...@feather.perl6.nl wrote:
+=head2 Semi-internal methods
+
+[This section is severely conjectural]
+
+For efficient implementation of arithmetics on C objects, two more
+methods are exposed:
+
+ $d.daycount
+ Date.new-from
In reading all of the discussion about Temporal, I have the uneasy
feeling that the current development work is falling into the same traps
as other languages. It seems to me that the underlying time-measurement
paradigm of the developers is too tightly focused on the Christian
Gregorian calend
Author: moritz
Date: 2010-04-21 10:54:00 +0200 (Wed, 21 Apr 2010)
New Revision: 30425
Modified:
docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
[S32::Temporal] remove .daycount method - use $date - $start_of_epoch to obtain
a day count starting from a fix epoch
Modified: docs/Perl6/Spec
(The following describes a proposed extension to Perl 6, methodical scoped
operators or methodicals for short. It is written in the present tense for
simplicity but should be understood as the future conditional.)
Normally, when you write a method call, the definition of the method is
entirely in
12 matches
Mail list logo
