Thanks for filing. I don't recall any reason for this and it seems bad
to break compatibility.
It may be that Norbert and Allen just missed your post on Monday; cc'ing
them.
/be
Mathias Bynens wrote:
On 19 Aug 2013, at 11:25, Mathias Bynensmath...@qiwi.be wrote:
After comparing the
Hi all,
Thanks for your answers.
Domenic Denicola sent me an example by email, but I don't understand it all.
I waited for his response, but seemed busy, I turn back to you.
The sample :
Hello everyone,
I wondered why it would be possible to send only one variable via this
method?
Knowing that we will have the opportunity to use destructuring assignments, why
can't we deal on this problem?
Thanks in advance.
___
es-discuss mailing
It already is dealt with via destructuring assignments:
```js
function* gen() {
var {x, y, z} = yield [1, 2, 3]
return x y || z
}
var g = gen()
var [a, b, c] = g.next().value
assert(a === 1)
assert(b === 2)
assert(c === 3)
var res = g.send({x: true, y: false, z: true}).value
assert(res ===
`g.next()` returns `{value: [1, 2, 3], done: false}` for me, so .value
is needed here. Or do you mean something else?
Thanks,
André
No .value anywhere, though.
/be
Forbes Lindesay wrote:
/ It already is dealt with via destructuring assignments:
//
// ```js
// function* gen() {
// var
I just wanted to demonstrate the point, I couldn't remember what the exact API
agreed upon for `gen.send` is.
On 23 Aug 2013, at 10:07, Andr? Bargull
andre.barg...@udo.edumailto:andre.barg...@udo.edu wrote:
`g.next()` returns `{value: [1, 2, 3], done: false}` for me, so .value is
needed here.
The `=` operator in the object declaration is defining defaults for the
destructuring. If the object being destructured doesn't have that property,
the value on the right hand side of the `=` operator is used.
The `= {}` provides a default object to de-structure, making the entire
argument
I believe .value is indeed correct, although as André alludes to, .send() has
been replaced by .next().
[Working example in Traceur][1] (this is fun!)
[1]:
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#august_23_2013_draft
Changes include:
Added Number.isSafeInteger
Added Number.MAX_SAFE_INTEGER
Removed: Number.MAX_INTEGER
Removed: Number.toInteger
Define all parts of a class definition to be strict code
‘length’ property
Is there any particular reason my JS doesn't support (optional) AS3 style
strong typing? All the typing info would be ignored at run-time, but it
would be helpful for compile-time checking, code hinting, and general
readability of code. Tools like the closure compiler could even strip out
all the
On 13-08-23 08:51 AM, Allen Wirfs-Brock wrote:
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#august_23_2013_draft
When I view the PDFs in Adobe Reader, most of the body text is rendered
in Adobe Sans MM, which is what it substitutes when it can't locate the
original
On Fri, Aug 23, 2013 at 10:51 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#august_23_2013_draft
The HTML version is now available:
https://people.mozilla.com/~jorendorff/es6-draft.html
As always, bug reports are greatly
I haven't personally used it, but you may find that TypeScript provides
what you're looking for: http://www.typescriptlang.org/
On Fri, Aug 23, 2013 at 1:26 PM, J B por...@gmail.com wrote:
Is there any particular reason my JS doesn't support (optional) AS3 style
strong typing? All the typing
I'm aware of TypeScript, as well as all of these:
https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
But those languages appear to have been created precisely because
ECMAScript lacks features like typing. How many of those languages offer
strong typing? I count
So the defacto response for large scale JS development will always be: Use
X?
On Fri, Aug 23, 2013 at 12:35 PM, Jeremy Martin jmar...@gmail.com wrote:
I haven't personally used it, but you may find that TypeScript provides
what you're looking for: http://www.typescriptlang.org/
On Fri, Aug
In general ECMAScript lacks lots of features. You may well ask why it doesn't
have any other pet feature, and you can often point to compile-to-JS languages
that add those. This doesn't imply that the feature should be added to the
language.
Here, let me try:
---
I'm aware of LispyScript, as
For one, I wouldn't describe strong typing as a pet feature. Two, no, as
far as I know, most of those languages in that list don't offer macros or
lots of parentheses; and, if they did, then, yeah, maybe it does say
something.
On Fri, Aug 23, 2013 at 12:41 PM, Domenic Denicola
And just to be clear, I'm not asking for run-time type checking or
coercion; I'm simply asking that the interpreter not to thrown an error
when it encounters something like this: var foo:String;
On Fri, Aug 23, 2013 at 12:45 PM, J B por...@gmail.com wrote:
For one, I wouldn't describe strong
var foo:String;
That's already a compile-time error (as opposed to runtime not sure if
that's what you meant by the interpreter throwing an error).
On Fri, Aug 23, 2013 at 1:56 PM, J B por...@gmail.com wrote:
And just to be clear, I'm not asking for run-time type checking or
coercion;
Are you referring to browsers like Chrome that compile the JS first? Then,
yeah, I mean it shouldn't throw an error at compile time.
On Fri, Aug 23, 2013 at 12:59 PM, Jeremy Martin jmar...@gmail.com wrote:
var foo:String;
That's already a compile-time error (as opposed to runtime not
Evolving a language standard used as broadly as ECMAScript takes time. You can
see TypeScript as exploring future options for ECMAScript.
Guards [1] may still be added to ECMAScript, I don’t know what the current TC39
opinion is on them.
Lastly, TypeScript tracks JavaScript very closely, I
I mean it's a parse error that will throw prior to attempting to execute
it. For example, consider:
(function() { var foo:String; })
This will throw an error, despite the fact that the function hasn't been
invoked. I replied in haste, though... your point is obviously valid for
other
@Jeremy: I mean the parser will strip all of the typing info out before
it's compiled/interpreted.
@Axel: Evolving a language standard used as broadly as ECMAScript takes
time -- I agree.
You can see TypeScript as exploring future options for ECMAScript. --
Wasn't AS3 already doing this?
Guards
Domenic Denicola wrote:
[Working example in Traceur][1] (this is fun!)
Yes, +lots for Traceur.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
André Bargull wrote:
`g.next()` returns `{value: [1, 2, 3], done: false}` for me, so .value
is needed here. Or do you mean something else?
Sorry (to Forbes), I was thinking of when for-of orchestrates.
/be
Thanks,
André
No .value anywhere, though.
/be
Forbes Lindesay wrote:
/ It
Has everyone forgotten ES4? Blasts from the past:
https://brendaneich.com/2007/11/my-media-ajax-keynote/
and then
https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html
ES4 failed in part because of AS3 namespaces (from original JS2/ES4
namespaces in 1999, also in JScript.NET
I mean the parser will strip all of the typing info out before it's
compiled/interpreted.
The implication being that implementors start shipping static compilers
where this parsing/stripping takes place (i.e., as a precursory step to
being interpreted)?
but it's been made worse by ECMAScript's
Also, unlike other language features, static typing has it's own section in
that list; and they're not all in that section: Some of the ones listed
below are also statically typed, such as mobl, GWT, JSIL, NS Basic, and
Haxe.
So, yeah, I don't think it qualifies as a pet feature.
None of this
@Brendan - The typing wouldn't be used at all during run-time. So, unlike
AS3, it wouldn't check if types were valid, and it wouldn't try an kind of
implicit coercion.
@Jeremy - The implication being that implementors start shipping static
compilers where this parsing/stripping takes place (i.e.,
J B wrote:
@Brendan - The typing wouldn't be used at all during run-time. So,
unlike AS3, it wouldn't check if types were valid, and it wouldn't try
an kind of implicit coercion.
Ok, that's not typing (I mean not a type system).
Those are warnings, but WarnScript was a bad name - me at
@Brendan Those are warnings, but WarnScript was a bad name --you mean the
tools (IDEs, closure compiler, etc) throw warnings, but not the Chrome
debugger, for instance, right?
On Fri, Aug 23, 2013 at 2:37 PM, Brendan Eich bren...@mozilla.com wrote:
J B wrote:
@Brendan - The typing wouldn't
https://brendaneich.com/2007/11/my-media-ajax-keynote/ I liked reading
this...
https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html This
is depressing.
On Fri, Aug 23, 2013 at 2:50 PM, J B por...@gmail.com wrote:
@Brendan Those are warnings, but WarnScript was a bad name
TypeScript are a move from Microsoft to become JavaScript more friendly to
VisualStudio developers. And to try typed scenarios.
I'm a VisualStudio-developer, and for years, I didn't need typed JavaScript
(as I didn't need type Python or Ruby). I feel that is the case with many
developers.
I
On Fri, Aug 23, 2013 at 1:20 PM, J B por...@gmail.com wrote:
https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html This
is depressing.
J B,
You’re entitled to a dissenting opinion. However, this archives one of the
best moments for the evolution of the language. It was a
That said, note that your sentiment has been graciously heard. What you
are asking for is well-represented by rigorous research going into
TypeScript, which is very closely aligned with work and proposals that came
out of these discussions. I believe it is fair to interpret Brendan’s last
On Aug 23, 2013, at 1:20 PM, J B por...@gmail.com wrote:
On Fri, Aug 23, 2013 at 2:50 PM, J B por...@gmail.com wrote:
@Brendan Those are warnings, but WarnScript was a bad name --you mean the
tools (IDEs, closure compiler, etc) throw warnings, but not the Chrome
debugger, for instance,
Brendan Eich wrote:
The Chrome dev tools (Firefox devtools, etc.) can cope -- but the burning
question
is: will we have more type confusion bugs or fewer if we standardize
warning annotations.
/be
___
es-discuss mailing list
I'd rather be corrected when I'm right than ignored when I'm wrong, and at the
moment I'm still pretty new to the specifics of ES6 APIs :)
On 23 Aug 2013, at 19:44, Brendan Eich bren...@mozilla.com wrote:
André Bargull wrote:
`g.next()` returns `{value: [1, 2, 3], done: false}` for me, so
38 matches
Mail list logo
