Methodicals: A better way to monkey type

2010-04-21 Thread Stefan O'Rear
(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

r30425 - docs/Perl6/Spec/S32-setting-library

2010-04-21 Thread pugs-commits
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:

Proposal for a new Temporal time-measurement paradigm

2010-04-21 Thread Richard Hainsworth
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

Re: r30398 - docs/Perl6/Spec/S32-setting-library

2010-04-21 Thread Moritz Lenz
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 CDate objects, two more +methods are exposed: + + $d.daycount +

Re: r30425 - docs/Perl6/Spec/S32-setting-library

2010-04-21 Thread Mark J. Reed
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:

Re: Methodicals: A better way to monkey type

2010-04-21 Thread John Harrison
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

Re: Methodicals: A better way to monkey type

2010-04-21 Thread Mark J. Reed
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, world!

Re: Methodicals: A better way to monkey type

2010-04-21 Thread Daniel Ruoso
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

Re: Proposal for a new Temporal time-measurement paradigm

2010-04-21 Thread Matthew
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

Re: Methodicals: A better way to monkey type

2010-04-21 Thread Stefan O'Rear
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 gets to

Re: Proposal for a new Temporal time-measurement paradigm

2010-04-21 Thread Mark J. Reed
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