I can see why, since nearly everyone depends on that coupling. Minifiers
depend on it. Mixin utilities depend on it. Breaking the Web would be an
understatement.
On Wed, Aug 12, 2015, 14:36 Brendan Eich bren...@mozilla.org wrote:
Caitlin Potter wrote:
ES2015 already has element accessor
Oh. Pardon my ignorance. Misunderstood the idea.
On Wed, Aug 12, 2015, 23:19 Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Aug 12, 2015, at 7:30 PM, Isiah Meadows wrote:
I can see why, since nearly everyone depends on that coupling. Minifiers
depend on it. Mixin utilities depend on it.
Oh, forgot to add a bit to those snippets to divide the bytes_per_element into
bits, but yeah
On Aug 11, 2015, at 2:55 PM, Michael McGlothlin mike.mcgloth...@gmail.com
wrote:
SIMD types appear almost as limited in size as using numbers. Often I need to
manipulate thousands or millions of
Well, you could just use typed arrays for this, and add a helper function which
retrieves the bit at a specific index. Like, something like this:
```
function bitset_get(ta, i) {
var e = (i / ta.BYTES_PER_ELEMENT) | 0;
i = i % ta.BYTES_PER_ELEMENT;
return (ta[e] i) 1;
}
```
You could
ES2015 already has element accessor overloading with proxies, right?
It's everything else that's missing.
Proxies enforce invariants, which is problematic for this use case because it’s
A) expensive, and B) also restricts you from “lying” about the actual
properties which exist on the
On Wed, Aug 12, 2015 at 4:50 AM, Caitlin Potter caitpotte...@gmail.com wrote:
Operator overloading or value types might make it look a lot prettier some
day (though iirc element assessor overloading was off limits), but you could
get pretty far by baking it into a compile-to-js language.
Also `instanceof` overloading via `Symbol.hasInstance`
On Wed, Aug 12, 2015 at 10:44 AM, Daniel Ehrenberg dehrenb...@chromium.org
wrote:
On Wed, Aug 12, 2015 at 4:50 AM, Caitlin Potter caitpotte...@gmail.com
wrote:
Operator overloading or value types might make it look a lot prettier
some
SIMD types appear almost as limited in size as using numbers. Often I need to
manipulate thousands or millions of bits efficiently so fumbling around with
numbers is messy.
I've looked at several implementations on npm but none seemed very mature or
standard.
I guess it's philosophical as
Bits and bytes are fundamental to JavaScript too, which is why the
language has, for a long time, included operations like , , ,
, |, ^ and ~ on Numbers, exposing the ability to manipulate 32-bit
integers. This is comparable to what C provides. Like C, JavaScript
has a relatively minimal standard
Daniel Ehrenberg wrote:
Uint8ClampedArray is more of a historical artifact than something you
should actually aim to use. Uint8Array is probably what you'd want to
get at as a basis for a user-level library.
Thanks for posting this, Daniel. Just to be super-clear (and I was
around when it was
I don't think my earlier mail went through, so I'm posing it below for
the record:
SIMD types have bitwise operators, but SIMD.js exposes just fixed-size
vectors that are optimized to what hardware can optimize certain
operations for. A future extension (the long SIMD API) may operate
on
Do SIMD types solve your problem?
https://github.com/tc39/ecmascript_simd
On Mon, Aug 10, 2015, 10:58 Michael McGlothlin mike.mcgloth...@gmail.com
wrote:
Would there be a downside to extending Bitwise operators to work with
typed arrays such as UInt8ClampedArray? To me it seems natural to
12 matches
Mail list logo