Hi Norbert,
Sorry for not having better explained my suggestion.
`var date = Date.withTimeZone(America/Los_Angeles, 2013, 3, 9, 15, 11,
0);` would create a Date object with a local time for
America/Los_Angeles, regardless of my computer's timezone. The difference
is that calls to date.getHours
Le 15 avr. 2013 à 09:27, Sorin Mocanu sorinmoc...@google.com a écrit :
Hi Norbert,
Sorry for not having better explained my suggestion.
`var date = Date.withTimeZone(America/Los_Angeles, 2013, 3, 9, 15, 11, 0);`
would create a Date object with a local time for America/Los_Angeles,
Hi,
I've noted that it is a Syntax error to write things like `if (foo) let x;` or
`while (bar) let x;` (without block enclosing the `let x` statement), both in
the latest version of FF and Chrome (appropriate experimental flags enabled),
which is a very reasonable behaviour. However, I was
On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
On Apr 9, 2013, at 15:23 , Nebojša Ćirić wrote:
I'll add this as a second option to the strawman.
2013/4/9 Sorin Mocanu sorinmoc...@google.com
Thank you Nebojša.
How about if the
Statements and Declarations are separate production rules (cf. 12
Statements and Declarations in the draft), only a Statement can be
nested directly within an if-Statement.
- André
Hi,
I've noted that it is a Syntax error to write things like `if (foo) let x;` or
`while (bar) let x;`
Le 15 avr. 2013 à 14:43, Dean Landolt d...@deanlandolt.com a écrit :
On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
On Apr 9, 2013, at 15:23 , Nebojša Ćirić wrote:
I'll add this as a second option to the strawman.
2013/4/9
I think we can all agree that, in principle, program structures which have
scope and define a namespace should be lexically identified and should
nest, unless there is some compelling reason otherwise.
A module, for any sane definition of the term in the context of Javascript,
has a scope and
Le 15 avr. 2013 à 15:29, André Bargull andre.barg...@udo.edu a écrit :
Statements and Declarations are separate production rules (cf. 12 Statements
and Declarations in the draft), only a Statement can be nested directly
within an if-Statement.
- André
Indeed, thanks.
—Claude
Hi,
Perhaps I wasn't clear: I was proposing the timezone property as purely
informative for the locale methods. The Date constructor used to revive the
IDB value will dictate the date's timezone, so no, the cloned date wouldn't
carry its timezone with it. However, in my proposed world it would be
On Mon, Apr 15, 2013 at 10:01 AM, Dean Landolt d...@deanlandolt.com wrote:
Perhaps I wasn't clear: I was proposing the timezone property as purely
informative for the locale methods. The Date constructor used to revive the
IDB value will dictate the date's timezone, so no, the cloned date
On Mon, Apr 15, 2013 at 6:41 AM, Kevin Smith zenpars...@gmail.com wrote:
I think we can all agree that, in principle, program structures which have
scope and define a namespace should be lexically identified and should
nest, unless there is some compelling reason otherwise.
A module, for any
On Apr 15, 2013, at 5:43 , Dean Landolt wrote:
On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
I'm afraid this would be quite confusing. Many people believe already that
Date instances are in some local time zone, which they aren't, and this
On Apr 15, 2013, at 6:00 AM, Arthur Barstow wrote:
On 4/15/13 5:02 AM, ext Robin Berjon wrote:
Note that next week there's a four-day meeting in San Jose involving HTML,
WebApps, WebAppSec, and Web Crypto (at least). It's a bit short notice, but
maybe we can experiment that there?
I
On 15 April 2013 17:13, Mark S. Miller erig...@google.com wrote:
On Mon, Apr 15, 2013 at 6:41 AM, Kevin Smith zenpars...@gmail.com wrote:
I think we can all agree that, in principle, program structures which have
scope and define a namespace should be lexically identified and should nest,
On Mon, Apr 15, 2013 at 11:46 AM, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
On Apr 15, 2013, at 5:43 , Dean Landolt wrote:
On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
I'm afraid this would be quite confusing. Many
Hi Kevin, if nothing in the ES6 module system precludes lexical modules,
why is postponing lexical modules and conceptual integrity till ES7 not an
option? In the same sense, we likewise postponed most of what is needed for
classes to have conceptual integrity (as well as literal integrity
On Apr 15, 2013, at 2:02 AM, Robin Berjon wrote:
I heartily agree with the sentiment in these three proposals, but I'm not
sure that they're the best approach.
To begin with, I can't formally speak on behalf of all the API-making groups
but I would be very surprised if they weren't
On Apr 15, 2013, at 9:23 , Dean Landolt wrote:
On Mon, Apr 15, 2013 at 11:46 AM, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
On Apr 15, 2013, at 5:43 , Dean Landolt wrote:
On Sun, Apr 14, 2013 at 10:49 PM, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
Inspired by DOM adding Futures http://dom.spec.whatwg.org/#futures,
I've begun reworking several APIs in terms of them. While doing so,
I've found several spots where Futures aren't appropriate, because I
need something that can be updated multiple times, rather than just
representing a single
Node.js has multiple iterations on Streams, and those were made in the hope
to make them better. It's hard and has been an ongoing effort to make it
perfect.
That said it's quite surprising to see smart folks come to such different
conclusions. Perhaps it's the lack of real life implementations
It's a nice effort but I agree with Nuno that fragmentation even on these
things already in production (despite the versioning) out there and already
working practically for the real-world isn't any good for the next future
of the JS community.
Also, JS has been kept general purpose enough, I
On Mon, Apr 15, 2013 at 1:51 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
It's a nice effort but I agree with Nuno that fragmentation even on these
things already in production (despite the versioning) out there and already
working practically for the real-world isn't any good for
I've implemented Alex Future proposal in JS before he did as prototype and
for tests.
However, Futures aren't used that much in node.js and spec'd like that are
nice.
However, I would not compare those two things.
If you propose Streams after Futures where Futures are less common in node
but
of course, that is just my opinion.
I am looking forward to read others ... meanwhile, in texas JS, a talk
about node streams:
http://2013.texasjavascript.com/stream/
Regards
On Mon, Apr 15, 2013 at 2:12 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I've implemented Alex Future
If fragmentation is bad why propose something that was never experimented
and diverged completely from what we learned with node?
Would love to understand the technical merits on why this is better than
node streams and why streams need to be in JS. I'm sure you have a
reasoning, i for once would
I think a large part of the confusion here is that when Tab says streams he
really means observables or signals. As you point out, this would be
completely inappropriate as a stream API, as it does indeed ignore many of the
lessons Node learned. Surprisingly, it doesn't seem to draw on any of
well, if the purpose is different and you need to describe streams as
observables or signals then I would suggest to change naming convention
so nobody will ever be confused again.
On Mon, Apr 15, 2013 at 2:36 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
I think a large part of
On Mon, Apr 15, 2013 at 2:36 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
I think a large part of the confusion here is that when Tab says streams
he really means observables or signals. As you point out, this would be
completely inappropriate as a stream API, as it does indeed
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
I do somewhat resent the implication that I invented something wholly new
without drawing on any existing APIs. I looked at the syntaxes of several
similar APIs in other languages while designing this, and took lessons from
them.
In
On Mon, Apr 15, 2013 at 2:13 PM, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
On Apr 15, 2013, at 9:23 , Dean Landolt wrote:
On Mon, Apr 15, 2013 at 11:46 AM, Norbert Lindenberg
ecmascr...@lindenbergsoftware.com wrote:
On Apr 15, 2013, at 5:43 , Dean Landolt wrote:
On Mon, Apr 15, 2013 at 3:40 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
I do somewhat resent the implication that I invented something wholly new
without drawing on any existing APIs. I looked at the syntaxes of several
similar
Would it help to split the sugar and combinator from the actual stream
interface?
```
callback StreamInit = void (StreamResolver resolver);
callback AnyCallback = any (optional any value);
[Constructor(StreamInit init)]
interface Stream {
Stream listen(optional AnyCallback? listenCB = null,
On Mon, Apr 15, 2013 at 4:24 PM, Jake Verbaten rayn...@gmail.com wrote:
Would it help to split the sugar and combinator from the actual stream
interface?
```
callback StreamInit = void (StreamResolver resolver);
callback AnyCallback = any (optional any value);
[Constructor(StreamInit
On Mon, Apr 15, 2013 at 7:35 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
It should also be made clear how and when a stream may emit values. Whether
it is at any arbitrary time and it will send to whomever is listening at
that moment. Whether it is only allowed to emit values after a listen
On Mon, Apr 15, 2013 at 4:43 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Mon, Apr 15, 2013 at 7:35 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
It should also be made clear how and when a stream may emit values. Whether
it is at any arbitrary time and it will send to whomever is
I think all of these are only suited for single-consumer streams. My
original proposal is explicitly for multi-consumer streams, as I
designed it explicitly for DOM use-cases that I ran into.
Most streams I've used have been single consumer streams. Whether I write
FRP style programs with
If this is really about multiple-consumer streams, the semantics of this
proposed API are incredibly murky to me. What happens if each consumer
calls next()? Do they all get the same value out of their Future when it's
completed? Do they each randomly get one of the values pushed into the
stream?
On Mon, Apr 15, 2013 at 5:03 PM, Jake Verbaten rayn...@gmail.com wrote:
I think all of these are only suited for single-consumer streams. My
original proposal is explicitly for multi-consumer streams, as I
designed it explicitly for DOM use-cases that I ran into.
Most streams I've used have
On Mon, Apr 15, 2013 at 5:06 PM, Kevin Gadd kevin.g...@gmail.com wrote:
If this is really about multiple-consumer streams, the semantics of this
proposed API are incredibly murky to me. What happens if each consumer calls
next()? Do they all get the same value out of their Future when it's
On Mon, Apr 15, 2013 at 2:04 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
Also, JS has been kept general purpose enough, I would not try to
influence
the language too much after DOM and W3C APIs and I thought this was also
same idea of TC39.
I don't understand this sentence. It
OK, it sounds like this is sort of a 'lossy' stream concept, then, in that
if you fail to call next() early enough, you can miss data from the stream?
I can see how that would be acceptable for certain use cases. To me though,
this limits use of the primitive.
Here's a hypothetical. I'm building
So one thing that is confusing is that `next()` has an API that looks like
the stream is a pull stream. A pull stream means that you call next()
and it will give you the next value when it has it. This type of stream
generally buffers values internally and only gives you them when you pull
them
how about .pull() then, to read, and .push() to write :D
On Mon, Apr 15, 2013 at 5:34 PM, Jake Verbaten rayn...@gmail.com wrote:
So one thing that is confusing is that `next()` has an API that looks like
the stream is a pull stream. A pull stream means that you call next()
and it will give
On Mon, Apr 15, 2013 at 5:34 PM, Jake Verbaten rayn...@gmail.com wrote:
So one thing that is confusing is that `next()` has an API that looks like
the stream is a pull stream. A pull stream means that you call next()
and it will give you the next value when it has it. This type of stream
On Mon, Apr 15, 2013 at 5:37 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
how about .pull() then, to read, and .push() to write :D
Node experience notwithstanding, long experience with Promises/etc
showed that mixing the promise and the resolver in a single object is
a bad idea. I
On Mon, Apr 15, 2013 at 5:26 PM, Kevin Gadd kevin.g...@gmail.com wrote:
OK, it sounds like this is sort of a 'lossy' stream concept, then, in that
if you fail to call next() early enough, you can miss data from the stream?
I can see how that would be acceptable for certain use cases. To me
46 matches
Mail list logo
