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" wrote:
> André Bargull wrote:
>> `g.next()` returns `{value: [1, 2, 3], done: false}` for me, so .value is
>> need
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
es-discuss@mozilla.org
On Aug 23, 2013, at 1:20 PM, J B wrote:
> On Fri, Aug 23, 2013 at 2:50 PM, J B 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, right?
The Chrome dev tool
"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
sentimen
On Fri, Aug 23, 2013 at 1:20 PM, J B 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 commitment to
focu
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 guess
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 wrote:
> @Brendan "Those are warnings, but WarnScript was a bad name" --you mean
> the t
@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 wrote:
> J B wrote:
>
>> @Brendan - The typing wouldn't be used at all
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 - 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.,
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
> 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'
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
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 alrea
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
@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?
"Guar
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 scenar
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 woul
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 wrote:
> > var foo:String;
>
> That's already a compile-time error (as opposed to runtime not sure if
> that's
> 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 wrote:
> And just to be clear, I'm not asking for run-time type checking or
> coercion; I'm simply aski
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 wrote:
> For one, I wouldn't describe strong typing as a "pet
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 <
dome...@domenic
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
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 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 23, 2013 at
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 q
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 wrote:
> Is there any particular reason my JS doesn't support (optional) AS3 style
> strong typing? All the typing info would be i
On Fri, Aug 23, 2013 at 10:51 AM, Allen Wirfs-Brock
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 appreciated. Send me e
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 fon
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 t
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 of
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://traceur-compiler.googlecode.com/git/demo/repl.html#function*%20gen%28%29%20{%0A%20%20var%20{x%2C%20y%2C%20z}%20%3D%20yield%20[1%2C%2
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 opt
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"
mailto:andre.barg...@udo.edu>> wrote:
`g.next()` returns `{value: [1, 2, 3], done: false}` for me, so .value is
needed here. Or do you mean so
`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() {
/>/
No .value anywhere, though.
/be
Forbes Lindesay wrote:
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
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 ===
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 li
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 :
http://traceur-compiler.googlecode.com/git/demo/repl.html#function%20postToMailingList%28{%0A%20%20%20%20em
38 matches
Mail list logo
