On 2012-11-18 10:49 PM, Brendan Eich wrote:
Brendan Eich wrote:
I agree that * or other operators should not be naively supported on
arrays, which are not value objects in any case. Any vector or matrix
value object would want sweet literal syntax, but it wouldn't be array
literal syntax,
I like this as a rough solution. Assuming we get Array sub-typing done in a
similar timeframe, it might all fold into a nice tidy package.
On Nov 19, 2012, at 3:08 AM, Brendan Eich bren...@mozilla.com wrote:
Oliver Hunt wrote:
On Nov 18, 2012, at 6:17 PM, Matt Calhouncalhoun...@gmail.com
I think it's a good time for me to point out the DSP API [1] again, which
is designed for fast vector math. There's already a partial node.js
implementation [2] by me and Jens Nockert is working on a SpiderMonkey
implementation, which is more complete atm.
Cheers,
Jussi
[1]
On 16 November 2012 22:01, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
P.S. Alex, just to be as clear as possible, one answer I did not like that
much was that eval('no strict') nonsense ... that was not an answer 'cause
problems are the same with eval('use strict')
No, they are not.
Douglas Crockford wrote:
Or we could put more methods on Array.prototype like .add(a), .mul(a),
.dot(a), .cross(a). And more functions on Array like .identity(n) and
.matrix(m, n, value).
This seems like something for library authors to try, using ES5 to make
the method additions
Le 14/11/2012 10:34, Andreas Rossberg a écrit :
On 14 November 2012 09:30, Tom Van Cutsem tomvc...@gmail.com wrote:
2012/11/13 David Bruant bruan...@gmail.com
For the particular case you've written, when going for hasOwnProperty.call
or the in operator, the JS engine knows it needs to output a
David Bruant wrote:
So my position is let's not bake performance bottlenecks in the
language (which we tend to do naturally anyway) and for things that
can be optimized, let's say that the implementations will pay the cost
of the static/runtime analysis if it's really felt by them like a
Le 19/11/2012 12:37, Brendan Eich a écrit :
David Bruant wrote:
So my position is let's not bake performance bottlenecks in the
language (which we tend to do naturally anyway) and for things that
can be optimized, let's say that the implementations will pay the
cost of the static/runtime
On 19 November 2012 13:04, David Bruant bruan...@gmail.com wrote:
I wish to point out a little thought on the topic of memory management. As
far as I know, all GC algorithms I'm aware of are runtime algorithms,
meaning that the primitives of these algorithms are objects and references
between
On 19 November 2012 13:04, David Bruant bruan...@gmail.com wrote:
I wish to point out a little thought on the topic of memory management. As
far as I know, all GC algorithms I'm aware of are runtime algorithms,
meaning that the primitives of these algorithms are objects and references
between
Claus Reinke wrote:
Also compile-time garbage collection or compile-time memory
management. Then there is the whole area of linear types or
uniqueness types,
affine types
which allow for in-place updating (reusing
memory) without observable side-effects when absence of other
references can
it's about changing behavior inline, both cases should throw an error.
I won't try, I am just saying what I think should happen.
Said that, I am off this thread, I have clarified already everything I
needed to clarify and I am OK with everything anyone will say here.
Happy Monday everybody :-)
On 17/11/2012, at 18:45, Brandon Benvie wrote:
The name property doesn't currently (and the I don't propose it should) have
a correlation to the name in scope. In function declarations the name is only
in scope because its declared in the outer scope, and this can be overwritten
function x(){ x = { name: 'y' }; return x.name } x(); // 'y'
(function x(){ x = { name: 'y' }; return x.name })() // 'x'
On Mon, Nov 19, 2012 at 2:29 PM, Jorge Chamorro Bieling
jo...@jorgechamorro.com wrote:
On 17/11/2012, at 18:45, Brandon Benvie wrote:
The name property doesn't
14 matches
Mail list logo
