I've been using some Number extensions of my own for some time:
Number.seconds, Number.minutes, Number.hours etc. where (2).minutes()
would return the 2 minutes expressed as milliseconds e.g. 120000,
(2).seconds() would return 2000 etc.
I think Rails does the same and that may be where I got the idea from.
I've also added Number.kilobytes, Number.megabytes, etc.
It would be great if interfaces which receive a time or quantity value
as an option, such as PeriodicalExecuter, could expect the value to be
expressed in the lowest common denominator unit practical, i.e.
milliseconds rather than seconds. Java does it, and so does
Javascript's own setInterval, setTimeout etc. It would follow the
principle of least surprise and make units of measurement easier to
compare.
The type of number extensions you described aren't part of prototype.
Therefore, it is simpler for developers who aren't using such an
extension to use seconds. I'm not opposed to the switch, but I wanted
to throw out a possible explanation for the way it is today.
On Fri, Oct 9, 2009 at 9:18 AM, Joran Greef <jorangr...@gmail.com> wrote:
> I've been using some Number extensions of my own for some time:
> Number.seconds, Number.minutes, Number.hours etc. where (2).minutes()
> would return the 2 minutes expressed as milliseconds e.g. 120000,
> (2).seconds() would return 2000 etc.
> I think Rails does the same and that may be where I got the idea from.
> I've also added Number.kilobytes, Number.megabytes, etc.
> It would be great if interfaces which receive a time or quantity value
> as an option, such as PeriodicalExecuter, could expect the value to be
> expressed in the lowest common denominator unit practical, i.e.
> milliseconds rather than seconds. Java does it, and so does
> Javascript's own setInterval, setTimeout etc. It would follow the
> principle of least surprise and make units of measurement easier to
> compare.
I, for one, found the units used by Function#delay (for example) to be
very surprising when I first saw them, and I have to stop and think
every time I use Function#delay. The usual unit for that sort of
thing in every language I've worked in other than BASIC is
milliseconds.
That said, I don't see changing them barring a wholescale Prototype
API rewrite.
-- T.J.
On Oct 9, 2:39 pm, Allen Madsen <bla...@gmail.com> wrote:
> The type of number extensions you described aren't part of prototype.
> Therefore, it is simpler for developers who aren't using such an
> extension to use seconds. I'm not opposed to the switch, but I wanted
> to throw out a possible explanation for the way it is today.
> On Fri, Oct 9, 2009 at 9:18 AM, Joran Greef <jorangr...@gmail.com> wrote:
> > I've been using some Number extensions of my own for some time:
> > Number.seconds, Number.minutes, Number.hours etc. where (2).minutes()
> > would return the 2 minutes expressed as milliseconds e.g. 120000,
> > (2).seconds() would return 2000 etc.
> > It's been great for defining config files e.g.:
> > I think Rails does the same and that may be where I got the idea from.
> > I've also added Number.kilobytes, Number.megabytes, etc.
> > It would be great if interfaces which receive a time or quantity value
> > as an option, such as PeriodicalExecuter, could expect the value to be
> > expressed in the lowest common denominator unit practical, i.e.
> > milliseconds rather than seconds. Java does it, and so does
> > Javascript's own setInterval, setTimeout etc. It would follow the
> > principle of least surprise and make units of measurement easier to
> > compare.
For the record, the unit of time measurement in Ruby is seconds, which
explains the reason behind that choice for Prototype.
Given the backwards compatibility issues, and the benefits of using
seconds rather than milliseconds in most but edge cases, there's litte
chance of seeing that change.
Best,
Tobie
On Oct 10, 2:30 pm, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
> I, for one, found the units used by Function#delay (for example) to be
> very surprising when I first saw them, and I have to stop and think
> every time I use Function#delay. The usual unit for that sort of
> thing in every language I've worked in other than BASIC is
> milliseconds.
> That said, I don't see changing them barring a wholescale Prototype
> API rewrite.
> -- T.J.
> On Oct 9, 2:39 pm, Allen Madsen <bla...@gmail.com> wrote:
> > Joran,
> > The type of number extensions you described aren't part of prototype.
> > Therefore, it is simpler for developers who aren't using such an
> > extension to use seconds. I'm not opposed to the switch, but I wanted
> > to throw out a possible explanation for the way it is today.
> > On Fri, Oct 9, 2009 at 9:18 AM, Joran Greef <jorangr...@gmail.com> wrote:
> > > I've been using some Number extensions of my own for some time:
> > > Number.seconds, Number.minutes, Number.hours etc. where (2).minutes()
> > > would return the 2 minutes expressed as milliseconds e.g. 120000,
> > > (2).seconds() would return 2000 etc.
> > > It's been great for defining config files e.g.:
> > > I think Rails does the same and that may be where I got the idea from.
> > > I've also added Number.kilobytes, Number.megabytes, etc.
> > > It would be great if interfaces which receive a time or quantity value
> > > as an option, such as PeriodicalExecuter, could expect the value to be
> > > expressed in the lowest common denominator unit practical, i.e.
> > > milliseconds rather than seconds. Java does it, and so does
> > > Javascript's own setInterval, setTimeout etc. It would follow the
> > > principle of least surprise and make units of measurement easier to
> > > compare.
Re: "...the unit of time measurement in Ruby is seconds, which
explains the reason".
Can we optimize for those familiar with Javascript? Is there any time-
related API in Javascript which uses seconds?
Re: "Given ... the benefits of using seconds rather than milliseconds
in most but edge cases".
Do you have some data on this?
Re: "backwards compatibility".
A semantically correct API may be better than a backwards compatible
API.
> Re: "...the unit of time measurement in Ruby is seconds, which > explains the reason". > Can we optimize for those familiar with Javascript? Is there any time- > related API in Javascript which uses seconds?
Well, programmers versed in more than one language can tell you that in general time APIs are in seconds, because second is canonical measure unit of time. Javascript is exception, and not in a good way. No need to follow bad examples...
> Re: "backwards compatibility". > A semantically correct API may be better than a backwards compatible > API.
Semantically correct API for time has units in seconds, because second is canonical unit for time, not 10e-3 seconds....
|
