On 21 October 2014 22:31, Mark S. Miller erig...@google.com wrote:
in saying that [weak maps] are not designed to work efficiently in that
manner.
Actually, they are. The problem is that initial implementations date from
before we appreciated the need for the transposed representation. The
FWIW the Multiple WeakMaps approach seems to be 2X ( Chrome ) up to 3X ( FF
Nightly ) faster than single WeakMap approach but I don't know how much
WeakMap instances cost in terms of GC operations so this bench might be
very pointless ( and surely it's premature )
Weirdly enough, Chrome Canary
On 22 October 2014 14:18, Andrea Giammarchi andrea.giammar...@gmail.com wrote:
FWIW the Multiple WeakMaps approach seems to be 2X ( Chrome ) up to 3X ( FF
Nightly ) faster than single WeakMap approach but I don't know how much
WeakMap instances cost in terms of GC operations so this bench might
I was trying to actually use same amount of indirections, since that's
probably more likely how real code might look like but you are right, hand
crafting per each case the pattern we have a different winner, which is the
single WeakMap instead of the multiple one.
I guess the reason is the
On Tue, Oct 21, 2014 at 11:59 PM, Andreas Rossberg rossb...@google.com
wrote:
On 21 October 2014 22:31, Mark S. Miller erig...@google.com wrote:
in saying that [weak maps] are not designed to work efficiently in that
manner.
Actually, they are. The problem is that initial implementations
Should be
var WeakMap;
(function() {
'use strict';
var SlowWeakMap = WeakMap;
function FastWeakMap() {
var token = Object.freeze(Object.create(null));
return Object.freeze({
get: function(key) {
var shadow = key.[[Shadow]];
return shadow ?
I know that this could clearly work for implementing private arrays, etc.
as well, but what about private integer or booleans?
```js
let _x = 0;
let _y = false;
class Foo {
constructor(x, y) {
this::_x = x;
this::_y = y;
}
// ...
}
___
On 10/22/2014 07:45 AM, Mark S. Miller wrote:
* Only objects that have been used as keys in FastWeakMaps would ever
have their [[Shadow]] set, so this could also be allocated on demand,
given only a bit saying whether it is present. Besides this storage of
this bit, there is no other effect
On Wed, Oct 22, 2014 at 1:44 PM, Steve Fink sph...@gmail.com wrote:
On 10/22/2014 07:45 AM, Mark S. Miller wrote:
* Only objects that have been used as keys in FastWeakMaps would ever
have their [[Shadow]] set, so this could also be allocated on demand,
given only a bit saying whether it
On Wed, Oct 22, 2014 at 5:26 PM, Mark Miller erig...@gmail.com wrote:
On Wed, Oct 22, 2014 at 1:44 PM, Steve Fink sph...@gmail.com wrote:
On 10/22/2014 07:45 AM, Mark S. Miller wrote:
* Only objects that have been used as keys in FastWeakMaps would ever
have their [[Shadow]] set, so
Please do nitpick. I wrote this in too much of a hurry and it is something
that needs care.
In any case, yes, transientKey.
On Wed, Oct 22, 2014 at 2:46 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Wed, Oct 22, 2014 at 5:26 PM, Mark Miller erig...@gmail.com wrote:
On Wed, Oct 22,
On 10/22/2014 02:26 PM, Mark Miller wrote:
On Wed, Oct 22, 2014 at 1:44 PM, Steve Fink sph...@gmail.com
mailto:sph...@gmail.com wrote:
On 10/22/2014 07:45 AM, Mark S. Miller wrote:
* Only objects that have been used as keys in FastWeakMaps would
ever
have their
On Wed, Oct 22, 2014 at 1:12 PM, Isiah Meadows impinb...@gmail.com wrote:
I know that this could clearly work for implementing private arrays, etc. as
well, but what about private integer or booleans?
```js
let _x = 0;
let _y = false;
class Foo {
constructor(x, y) {
this::_x = x;
My initial worries are largely around the ergonomics---both for authors
and implementers---if this is our solution for private state. In
particular, I don't think having to create a new WeakMap for every private
member is very author-friendly.
Even without private sugar, I think we could
Has the C# approach to namespace extension been considered at all?
With extension methods (one of the foundational primitives used to
implement their LINQ querying system) they address this by making
extension namespaces 'opt-in' - extension methods are only 'available'
on an object if you've
Katelyn Gadd wrote:
Has the C# approach to namespace extension been considered at all?
Yes. ES4 has namespaces, after Common Lisp symbol packages.
Scoped object extensions were proposed four years ago for ES6, but
foundered on the same thing that killed ES4 namespaces: adding a second
16 matches
Mail list logo
