Took a break while I worked on some Javascript projects for the past year to
see if they'd give me more perspective on types. I'll keep this short though.
Brendan Eich wrote:
No one is proposing type annotations a la ES4 or TypeScript, note well.
I'm thinking the discussion needs to start up
On Mon, Nov 24, 2014 at 9:00 AM, Brandon Andrews
warcraftthre...@sbcglobal.net wrote:
float32/64
- float16: common name: half, IEEE 754-2008: binary16, often used on GPUs
- float32: common name: float, IEEE 754-2008: binary32
- float64: common name: double, IEEE 754-2008: binary64
float16/80
decimal32/64/128
Those are reasonable additions also. Wasn't sure with decimal was going to
assume 128 bit for financial type applications. Having it vary with 32, 64, and
128 bit thought is much closer to the other suggestions. (I updated my original
post on esdiscuss to
On Mon, Oct 28, 2013 at 4:03 PM, Brendan Eich bren...@mozilla.com wrote:
Tristan Zajonc wrote:
Having === be reference equality is fine if that's a hard JS requirement.
For a matrix API, there is some flexibility on comparison operators, but
transient value comparison returning a single
Tristan Zajonc wrote:
if (mutMatA == mutMatB) {
accidentallyMutate(mutMatA);
assumeStillEqual(mutMatA, mutMatB, data);
}
Is this bug related to operator overloading? It seems just the nature
of the beast with mutable reference types. Pretty much all JS matrix
Tristan Zajonc wrote:
It's true that in JS today, comparing an object to a non-object,
valueOf or toString on the object can be used to make == results vary.
However, I'm proposing value objects with declarative syntax to
solve several problems:
1. Backward compatibility,
On Tue, Oct 29, 2013 at 10:04 AM, Brendan Eich bren...@mozilla.com wrote:
Tristan Zajonc wrote:
if (mutMatA == mutMatB) {
accidentallyMutate(mutMatA);
assumeStillEqual(mutMatA, mutMatB, data);
}
Is this bug related to operator overloading? It seems just the
On Tue, Oct 29, 2013 at 10:08 AM, Brendan Eich bren...@mozilla.com wrote:
Tristan Zajonc wrote:
It's true that in JS today, comparing an object to a non-object,
valueOf or toString on the object can be used to make == results vary.
However, I'm proposing value objects with
One clarification on the value objects proposal... The JSConf slides say
that immutability is implemented as an implicit Object.freeze(this) on
return in the constructor. Is this meant as shorthand for a deep freeze?
On Tue, Oct 29, 2013 at 11:13 AM, Tristan Zajonc
Tristan Zajonc wrote:
One clarification on the value objects proposal... The JSConf slides
say that immutability is implemented as an implicit
Object.freeze(this) on return in the constructor. Is this meant as
shorthand for a deep freeze?
Yes, although depth may be hard to generalize. A
Tristan Zajonc mailto:tris...@senseplatform.com
October 27, 2013 5:47 PM
I apologize for jumping in here with an incomplete understanding
what's being proposed, but perhaps somebody can help clarify it for
me. I've been following value types and operator overloading
discussion with great
Brendan Eich wrote:
The API Function.defineOperator(symbol, type1, type2) would be
perfect to support this. However I assume this is not the intention?
Is there any openness to supporting user defined infix operators or
at least an extended set similar to Python's PEP 225 proposal
On Mon, Oct 28, 2013 at 8:14 AM, Brendan Eich bren...@mozilla.com wrote:
Tristan Zajonc mailto:tristan@senseplatform.**comtris...@senseplatform.com
October 27, 2013 5:47 PM
I apologize for jumping in here with an incomplete understanding what's
being proposed, but perhaps somebody can help
Tristan Zajonc wrote:
Having === be reference equality is fine if that's a hard JS
requirement. For a matrix API, there is some flexibility on
comparison operators, but transient value comparison returning a
single boolean is the most natural, other issues aside. I'm not sure I
fully
On Sun, 10/27/13, Domenic Denicola dome...@domenicdenicola.com wrote:
Subject: RE: Proposal for new floating point and integer data types
To: Rick Waldron waldron.r...@gmail.com, Brandon Andrews
warcraftthre...@sbcglobal.net
Cc: es-discuss
Brandon Andrews mailto:warcraftthre...@sbcglobal.net
October 27, 2013 5:45 AM
On Sun, 10/27/13, Domenic Denicola dome...@domenicdenicola.com wrote:
Subject: RE: Proposal for new floating point and integer data types
To: Rick Waldron waldron.r
Brendan Eich wrote:
Here's what Alon wrote recently:
Alon Zakai, creator of Emscripten, first among discoverers of asm.js.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
for new floating point and integer data types
To: Rick Waldron waldron.r...@gmail.com, Brandon Andrews
warcraftthre...@sbcglobal.net**
Cc: es-discuss@mozilla.org es-discuss@mozilla.org
Date: Sunday, October 27, 2013, 12:18 AM
Also
http://www.slideshare.net/**BrendanEich/js-resp/5http
Sorry for the top post, but I recommend reading this:
http://wiki.ecmascript.org/doku.php?id=strawman:value_types
Rick
On Saturday, October 26, 2013, Brandon Andrews wrote:
I've seen posts asking for optional strong typing (often relating to
typescript), but not many asking for data types. I
@mozilla.org
Subject: Re: Proposal for new floating point and integer data types
Sorry for the top post, but I recommend reading this:
http://wiki.ecmascript.org/doku.php?id=strawman:value_types
Rick
On Saturday, October 26, 2013, Brandon Andrews wrote:
I've seen posts asking for optional strong
20 matches
Mail list logo
