Darren (>>>), Carl (>>), Darren (>):
>>> Specific units, even "seconds" should not be mentioned at all in the
>>> definition of "Instant" or "Duration"; instead, any particular units or
>>> calendars or whatever would just be a property of the composing class.
>>
>> No disrespect, but it was the ab
Carl Mäsak wrote:
Darren (>):
Specific units, even "seconds" should not be mentioned at all in the
definition of "Instant" or "Duration"; instead, any particular units or
calendars or whatever would just be a property of the composing class.
No disrespect, but it was the abandonment of abstrac
Darren (>):
> Specific units, even "seconds" should not be mentioned at all in the
> definition of "Instant" or "Duration"; instead, any particular units or
> calendars or whatever would just be a property of the composing class.
No disrespect, but it was the abandonment of abstracty stuff like th
To clarify, by "define particular methods" I mean that said 2 roles would
require composing classes to define them, not to include the code themselves. --
Darren Duncan
Darren Duncan wrote:
I think that "Instant" and "Duration" should simply be declarational
roles that don't have any implement
I think that "Instant" and "Duration" should simply be declarational roles that
don't have any implementation code to compose.
Composing "Instant" or "Duration" into a type simply says that the objects of
that type represent a point on a timeline or an amount of time.
Specific units, even "se
On 11/17/2010 10:08 PM, Martin D Kealey wrote:
Dimensioned numbers as restrictive types are useful, for uncovering bugs,
including sometimes latent ones in ported code.
Duration is a fairly clear example of a dimensioned quantity, and I think we
should think twice about abandoning its dimension
On Wed, 17 Nov 2010, Richard Hainsworth wrote:
> Once a number has been generated, viz., by obtaining a duration, that number
> can be manipulated however necessary. The interpretation of the number is a
> matter for the programmer, not the language designer.
All true.
However I'd argue that you
Moritz Lenz wrote:
> Am 17.11.2010 17:50, schrieb Jon Lang:
>> More generally, I wonder if maybe we _should_ provide a tool to help
>
> I think this question can only be answered in a meaningful way if somebody
> actually implements such a thing as a module (which should be entirely
> possible in R
Am 17.11.2010 17:50, schrieb Jon Lang:
If I'm following this correctly, shouldn't we just say that Duration
does Num?
Num is a class (think floating point number).
The role you're looking for is probably either Numeric or Real.
If we say that Duration inherits from Rat or FatRat, it automatica
If I'm following this correctly, shouldn't we just say that Duration
does Num? That way, a Duration can be used exactly like a Num is
(with units measured in seconds); but it could also have special
capabilities above and beyond what a Num can do, if such capabilities
are needed.
More generally,
Am 17.11.2010 15:20, schrieb Oha:
On 11/17/2010 02:56 PM, Carl Mäsak wrote:
Or, by Ockham, since Duration is now deprived of its only task --
making life harder for the programmer -- remove it altogether from the
language and just put a number type in its place, representing number
of seconds.
On Wed, Nov 17, 2010 at 2:20 PM, Oha wrote:
>
> I could be wrong but this reminds me that a Duration could not be only based
> in seconds, but also in other units (which may automagically be converted to
> seconds) and also those seconds may be leap or not.
>
> Maybe the point is that really the p
On 11/17/2010 02:56 PM, Carl Mäsak wrote:
Or, by Ockham, since Duration is now deprived of its only task --
making life harder for the programmer -- remove it altogether from the
language and just put a number type in its place, representing number
of seconds.
I could be wrong but this remind
I still have uses for Durations.
For instance, I want to dispatch a different .Stringy method to Durations than
to Nums. It's convenient to me that the difference between two Instants has a
different type than the difference between 1654321681.123 and 1654321021.65438.
I just think Durations
Mark (>):
> I'm not convinced that the type system shouldn't be helping with
> dimensional analysis, but at least it shouldn't hurt. By all means,
> let the programmer raise a Duration to a power - but the type of the
> result should not also be Duration. In the absence of automatic
> dimension t
I'm not convinced that the type system shouldn't be helping with
dimensional analysis, but at least it shouldn't hurt. By all means,
let the programmer raise a Duration to a power - but the type of the
result should not also be Duration. In the absence of automatic
dimension tracking, just return
Am 17.11.2010 14:02, schrieb Oha:
On 11/17/2010 01:46 PM, Moritz Lenz wrote:
Just as a data point, in physics duration squared does exist.
On the other hand, i can see why an Instant can't be used as a linear
value: it does not have a clear origin (or zero value).
That's correct, and the reas
On 11/17/2010 01:46 PM, Moritz Lenz wrote:
Just as a data point, in physics duration squared does exist.
On the other hand, i can see why an Instant can't be used as a linear
value: it does not have a clear origin (or zero value).
Therefore the multiplication of two Instant may results in diff
Am 17.11.2010 12:55, schrieb Richard Hainsworth:
On 11/17/10 14:03, Moritz Lenz wrote:
Am 17.11.2010 10:31, schrieb Kris Shannon:
$duration * $duration # WRONG, durations aren't geometric
$duration * 2 # ok, a duration twice as long
2 * $duration # same
What are your thoughts?
I've summarize
On 11/17/10 14:03, Moritz Lenz wrote:
Am 17.11.2010 10:31, schrieb Kris Shannon:
$duration * $duration# WRONG, durations aren't geometric
$duration * 2# ok, a duration twice as long
2 * $duration# same
What are your thoughts?
I've summarized my th
Am 17.11.2010 10:31, schrieb Kris Shannon:
A recent rakudo commit [1] is a quick fix for #78896 [2] to allow
exponentiation of Duration's.
And it did so with a real world use case in mind.
I'm uneasy with allowing this and I think the spec probably meant not
to but is badly
A recent rakudo commit [1] is a quick fix for #78896 [2] to allow
exponentiation of Duration's.
I'm uneasy with allowing this and I think the spec probably meant not
to but is badly worded [3]:
Durations allow additive operations with other durations, and allow
any numeric operat
22 matches
Mail list logo
