2013/2/14 Allen Wirfs-Brock al...@wirfs-brock.com
On Feb 13, 2013, at 12:53 PM, David Bruant wrote:
Interesting.
So what would happen when calling Object.isFrozen on a proxy? Would
Object.isFrozen/isSealed/isExtensible reach out directly to the target? or
a unique state trap returning a
2013/2/13 David Bruant bruan...@gmail.com
The trap in itself no, but it's possible to keep track of all exchanged
symbols and add them to the whitelists as they are observed before being
shared. It all relies on the fact that for 2 parties to exchange symbols,
they have to share it through a
Hey Allen, thanks for clarifying.
What will happen to other Array methods which currently return Arrays? `filter`
is the primary one that comes to mind. Will `uint32array.filter((v) = v != 0)`
return a Uint32Array? (I think it should behave the same way `map` does.)
Additionally, what will
On 14 February 2013 02:35, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
As we discussed at the meeting, to rationally place Typed Arrays into the
same class hierarchy as Array would require refactoring Array.prototype into
multiple abstract superclasses. This seems like too large of a
On 13 February 2013 13:39, David Bruant bruan...@gmail.com wrote:
Warning: In this post, I'll be diverging a bit from the main topic.
Le 12/02/2013 14:29, Brendan Eich a écrit :
Loss of identity, extra allocations, and forwarding overhead remain
problems.
I'm doubtful loss of identity
Nathan Wall wrote:
Hey Allen, thanks for clarifying.
What will happen to other Array methods which currently return
Arrays? `filter` is the primary one that comes to mind. Will
`uint32array.filter((v) = v != 0)` return a Uint32Array? (I think
it should behave the same way `map` does.)
I
If not, any particular reason these are not, being immutable and
representable similar to a C struct ?
If they could, any idea which engine is planning to optimize and when?
Thanks and Best Regards
___
es-discuss mailing list
es-discuss@mozilla.org
Frozen and sealed objects are both dramatically slower in most JS
engines I've tested. In the ones where they're not dramatically slower
they are never faster.
The last time I asked on the mozilla and v8 bug trackers I was
informed that there is no plan to optimize for these features and that
the
On Thu, Feb 14, 2013 at 10:01 AM, Kevin Gadd kevin.g...@gmail.com wrote:
Frozen and sealed objects are both dramatically slower in most JS
engines I've tested. In the ones where they're not dramatically slower
they are never faster.
The last time I asked on the mozilla and v8 bug trackers I
Kevin Gadd wrote:
Frozen and sealed objects are both dramatically slower in most JS
engines I've tested. In the ones where they're not dramatically slower
they are never faster.
The last time I asked on the mozilla and v8 bug trackers I was
informed that there is no plan to optimize for these
On Thu, Feb 14, 2013 at 10:09 AM, Herby Vojčík he...@mailbox.sk wrote:
Kevin Gadd wrote:
Frozen and sealed objects are both dramatically slower in most JS
engines I've tested. In the ones where they're not dramatically slower
they are never faster.
The last time I asked on the mozilla
On 14 February 2013 19:01, Kevin Gadd kevin.g...@gmail.com wrote:
The last time I asked on the mozilla and v8 bug trackers I was
informed that there is no plan to optimize for these features
Well, regarding V8, there is now. :)
/Andreas
___
On 14 February 2013 19:08, Mark S. Miller erig...@google.com wrote:
Based on history, I suggest that the best way to get this situation fixed is
benchmarks. Either create a new benchmark or a variation of an existing
benchmark. For example, if someone created a variant of SunSpider in which
Le 14/02/2013 18:11, Andreas Rossberg a écrit :
On 13 February 2013 13:39, David Bruant bruan...@gmail.com wrote:
Warning: In this post, I'll be diverging a bit from the main topic.
Le 12/02/2013 14:29, Brendan Eich a écrit :
Loss oread onlyf identity, extra allocations, and forwarding
It was just an example. Feel free to make an alternative and more informed
suggestion ;).
On Thu, Feb 14, 2013 at 10:15 AM, Andreas Rossberg rossb...@google.comwrote:
On 14 February 2013 19:08, Mark S. Miller erig...@google.com wrote:
Based on history, I suggest that the best way to get this
Le 14/02/2013 19:08, Mark S. Miller a écrit :
On Thu, Feb 14, 2013 at 10:01 AM, Kevin Gadd kevin.g...@gmail.com
mailto:kevin.g...@gmail.com wrote:
Frozen and sealed objects are both dramatically slower in most JS
engines I've tested. In the ones where they're not dramatically slower
Mark S. Miller wrote:
On Thu, Feb 14, 2013 at 10:09 AM, Herby Vojčík he...@mailbox.sk
mailto:he...@mailbox.sk wrote:
Kevin Gadd wrote:
Frozen and sealed objects are both dramatically slower in most JS
engines I've tested. In the ones where they're not dramatically
On 14 February 2013 19:16, David Bruant bruan...@gmail.com wrote:
Le 14/02/2013 18:11, Andreas Rossberg a écrit :
You're being vastly over-optimistic about the performance and the
amount of optimisation that can realistically be expected for proxies.
Proxies are inherently unstructured,
On 14 February 2013 01:05, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Where do without, means replaced with set/getIntegrity traps and objects
have explicit internal state whose value is one of
normal/non-extensible/sealed/frozen (and possibly) fixed-inheritance
between normal and
Andreas Rossberg wrote:
But more importantly, I think you get too hung up on proxies as the
proverbial hammer. Proxies are very much an expert feature. Using them
for random micro abstractions is like shooting birds with a nuke. A
language that makes that necessary would be a terrible language.
Andreas Rossberg wrote:
On 14 February 2013 19:26, Herby Vojčíkhe...@mailbox.sk wrote:
I meant de facto. People wanting to remove property bar from foo do not
write `delete foo.bar` anymore; they (at least some significant subset) have
learned to write `foo.bar = null;` or `foo.bar =
This is definitely the case. Recent performance guidance from V8
developers strongly discouraged the use of 'delete' so I've gone to
some lengths to avoid using it in my own code, mostly through design
(trying to avoid scenarios that require the deletion of attributes).
If this guidance isn't
On 14 February 2013 20:56, Herby Vojčík he...@mailbox.sk wrote:
The problem is proliferation of `foo.bar = null` in normal code, where
sometimes you want to remove some property (maybe it was an expando, or it
is realy not needed any more in the actual phases of the lifecycle). In such
cases,
On 14 February 2013 21:12, Kevin Gadd kevin.g...@gmail.com wrote:
I'm pleased to report that Object.freeze does not seem to cause an
enormous performance hit in v8 anymore. Hooray! Unfortunately, the
call to Object.freeze itself shows up as a bottleneck in V8 profiles,
and the 'freeze enabled'
the `delete obj.property` changes the shape of the object, right? so I
think is more a problem of devs using objects as trash bin but this is the
opposite scenario of a frozen object.
I understand ES5 descriptors are an overhead during an object lifecycle but
I think a mechanism to make frozen
On 14 February 2013 21:36, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Binary Arrays are indeed frozen objects, at least in Firefox, and ultra
fast:
Object.isFrozen(new Float32Array()) // true in Firefox
Since these are ultra fast in Chrome too but not frozen, I believe there is
One more thought ... the best scenario **ever** would be the ability to
define a frozen prototype and create already fixed shaped instance at
runtime.
I think Object.freeze() semantic is not the right one to do this, but I am
dreaming about something like this:
var MyStaticShapeConstructor =
I wodner how come Firefox behaves like that then but I don't have tests to
compare any difference between these two. I will write some, thanks
On Thu, Feb 14, 2013 at 12:48 PM, Andreas Rossberg rossb...@google.comwrote:
On 14 February 2013 21:36, Andrea Giammarchi
andrea.giammar...@gmail.com
Ideally the JIT would, at runtime, just identify the pattern where
your constructor ends with an Object.freeze(this) call, and turn it
into the equivalent of an immutable, pass-by-value packed struct. IIRC
v8 and SpiderMonkey are both able to do some of this already based on
looking at your
that is assuming nobody ever call the constructor without new keyword and
no inheritance is involved, since the sub constructor would be trapped
behind the parent.
That would be even more magic ... I kinda like it, not sure is explicit
enough though ... but yeah, if freeze(this) would do that, it
Andreas Rossberg wrote:
On 14 February 2013 19:16, David Bruantbruan...@gmail.com wrote:
Le 14/02/2013 18:11, Andreas Rossberg a écrit :
You're being vastly over-optimistic about the performance and the
amount of optimisation that can realistically be expected for proxies.
Proxies are
Andreas Rossberg wrote:
I'd say that either we properly clean up the Array hierarchy, or we
leave it alone. A half-baked solution that only applies to typed
arrays, and divorces them from the Array hierarchy, seems less
attractive than just doing the naive thing, i.e., TypedArray Array.
Agree
32 matches
Mail list logo
