domenic at domenicdenicola.com (2013-07-24T00:42:21.207Z)
On Wed, Jul 17, 2013 at 4:40 PM, Anne van Kesteren <annevk at annevk.nl> wrote:
> On Wed, Jul 17, 2013 at 1:04 PM, Rick Waldron <waldron.rick at gmail.com>
> wrote:
> > Can you explain why startDate was specified was a Date object?
>
> Because that's how JavaScript represents time?
Brendan's response is much nicer then mine.
> Event.timeStamp was
> supposed to be a Date object too:
> http://www.w3.org/TR/DOM-Level-2-Events/ecma-script-binding.html Not
> sure why it was not implemented that way.
>
I don't fully understand the point your trying to make, are you telling me
that these:
- http://dom.spec.whatwg.org/#event
- http://dom.spec.whatwg.org/#dom-event-timestamp
...Are not correct?
> I don't really follow your line of reasoning.
I apologize, let me try to clarify:
Time and/or timestamps represented as milliseconds since epoch, in the form
of a number, is useful for:
1. calculating time differences with math (without coercing the object into
a milliseconds number)
2. creating new Date objects if such a thing is necessary for the program
3. being the value of a property on a frozen object
4. being the value of a property who's descriptor is {[[Writable]]: false,
[[Enumerable]]: false, [[Configurable]]: false}
3 & 4 seem to be what you were looking for? 2 & 3 are just nice to have.
> Existing APIs use a mix
> of callbacks and events. Should we not switch to promises where we
> can, but rather stick with precedent?
>
>
The right paradigm for the job? I don't know what this has to do with the
subject of Date objects and epoch times, but if I had to guess, I'd say
you're trying to make my previous comments appear poorly conceived (in the
name of progress) because I used the word "precedent". Are you sure you
want to pick that fight?
From the perspective of someone with extensive practitioner experience
developing software for a variety of platforms, including web based video
programming with Popcorn.js (and without) and a variety of products built
on that framework, I had hoped to offer my sincerest, most constructive
feedback—but you're the boss, applesauce.
On Wed, Jul 17, 2013 at 4:40 PM, Anne van Kesteren <annevk at annevk.nl> wrote: > On Wed, Jul 17, 2013 at 1:04 PM, Rick Waldron <waldron.rick at gmail.com> > wrote: > > Can you explain why startDate was specified was a Date object? > > Because that's how JavaScript represents time? Brendan's response is much nicer then mine. > Event.timeStamp was > supposed to be a Date object too: > http://www.w3.org/TR/DOM-Level-2-Events/ecma-script-binding.html Not > sure why it was not implemented that way. > I don't fully understand the point your trying to make, are you telling me that these: - http://dom.spec.whatwg.org/#event - http://dom.spec.whatwg.org/#dom-event-timestamp ...Are not correct? > > I don't really follow your line of reasoning. I apologize, let me try to clarify: Time and/or timestamps represented as milliseconds since epoch, in the form of a number, is useful for: 1. calculating time differences with math (without coercing the object into a milliseconds number) 2. creating new Date objects if such a thing is necessary for the program 3. being the value of a property on a frozen object 4. being the value of a property who's descriptor is {[[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false} 3 & 4 seem to be what you were looking for? 2 & 3 are just nice to have. > Existing APIs use a mix > of callbacks and events. Should we not switch to promises where we > can, but rather stick with precedent? > > The right paradigm for the job? I don't know what this has to do with the subject of Date objects and epoch times, but if I had to guess, I'd say you're trying to make my previous comments appear poorly conceived (in the name of progress) because I used the word "precedent". Are you sure you want to pick that fight? >From the perspective of someone with extensive practitioner experience developing software for a variety of platforms, including web based video programming with Popcorn.js (and without) and a variety of products built on that framework, I had hoped to offer my sincerest, most constructive feedback—but you're the boss, applesauce. Rick > > -- > http://annevankesteren.nl/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130717/3d083af9/attachment.html>