Le 27/03/2013 01:55, David Herman a écrit :
But we need to take this into account as we consider what to do about weak
references in ES7.
From what I understand, doing exact rooting (instead of conservative
stack scanning) solves the problem or more precisely prevents the attack
by design
Le 27/03/2013 15:52, Brendan Eich a écrit :
Please read the memory safety and weak references thread.
The issue is not just SES, which might remove an iterator in preparing
the environment. Stock JS must not be vulnerable to jit-spray attacks
due to enumerable weak maps.
From what I
Le 26/03/2013 21:26, Brandon Benvie a écrit :
On 3/26/2013 1:03 PM, David Bruant wrote:
I'm starting to wonder whether bringing weakrefs is equivalent to
having iterable WeakMaps... And if so, why not make WeakMaps iterable?
This is a question I had as well. An iterable WeakMap is nearly
Le 26/03/2013 21:12, Allen Wirfs-Brock a écrit :
On Mar 26, 2013, at 12:18 PM, Mark S. Miller wrote:
WeakSet may or may not happen by ES6. But even if it doesn't, WeakSet
is trivially shimmable on WeakMap.
Set is also shimmable on top of Map. If Set is in, there are as many
reason to have
Le 26/03/2013 22:56, Mark S. Miller a écrit :
Because the weak-map-maker constructor grants no privilege and can be
generally accessible, whereas the weak-ref-maker grants the privilege
of being able to observe the non-determinism of GC, and so should not
be made accessible to code that
Le 20/03/2013 16:36, Nathan Wall a écrit :
I didn't get a direct response to my question about mutating proto on objects
which don't inherit from Object.prototype, but I'm inferring from [1] that it
won't be possible. I find this unfortunate, but I realize this issue has seen
a lot of
Le 20/03/2013 16:15, Brendan Eich a écrit :
To recap,
1. __proto__ is out in the field, a de-facto standard on mobile, and
not going away. Adding another API doesn't help, it hurts.
2. SES and other secure subsets want same-frame (global object,
realm) mashups of code that may use __proto__
Le 18/03/2013 17:48, Brendan Eich a écrit :
Andreas Rossberg wrote:
On 18 March 2013 17:32, Mark S. Millererig...@google.com wrote:
And why does ES5/strict impose these restrictions, when they are not
necessary for the formal criterion?
Because ES5 strict mode, being an opt-in, gave us a
Hi Andrea,
I'm really having a hard time understanding where the security issue is
here.
From what I understand, you've properly hidden the Private constructor.
I am not surprised if code can reach the [[Prototype]] of an instance
and I wouldn't consider that a flaw. I would consider that the
Le 17/03/2013 18:09, Andrea Giammarchi a écrit :
My concern is about being unable to let anyone retrieve that
property, for introspection or to pollute it or change it being able
to make my private constructor insecure.
In the example there but in other situation I cannot freeze the
prototype
Le 16/03/2013 19:18, Tom Schuster a écrit :
Hey!
Looking at the the steps for Object.is the first sentence just says:
When the is function is called with arguments value1 and value2 the following steps
are taken:
I don't remember other functions being defined like that. It should at
least
Le 14/03/2013 08:51, Tom Van Cutsem a écrit :
[+Allen]
2013/3/13 Nathan Wall nathan.w...@live.com mailto:nathan.w...@live.com
However, as a matter of principle, my argument is that
`Object.getOwnPropertyDescriptor` should, at the bare minimum,
return a descriptor that can be known
Le 14/03/2013 17:01, Brandon Benvie a écrit :
I also mentioned I thought it was unlikely to be commonly used, since
I've never seen it used besides some of my own code (which exists in a
couple libraries used by few or just me).
Sincere apologies on missing an important part of your quote (I
Le 12/03/2013 16:45, Tom Van Cutsem a écrit :
Hi Nathan,
2013/3/10 Nathan Wall nathan.w...@live.com mailto:nathan.w...@live.com
Given that `defineProperty` uses properties on the prototype of
the descriptor[1] and `getOwnPropertyDescriptor` returns an object
which inherits from
Le 13/03/2013 16:26, Nathan Wall a écrit :
David Bruant wrote:
Tom Van Cutsem wrote:
To my mind, the blame for the breakage lies with `Object.prototype`
being mutated by the third-party script, not with property descriptors
inheriting from Object.prototype. Thus, a fix for the breakage should
Le 13/03/2013 16:49, Mark S. Miller a écrit :
On Wed, Mar 13, 2013 at 8:26 AM, Nathan Wall nathan.w...@live.com
mailto:nathan.w...@live.com wrote:
David Bruant wrote:
Tom Van Cutsem wrote:
To my mind, the blame for the breakage lies with
`Object.prototype`
being
Le 11/03/2013 22:51, Andrea Giammarchi a écrit :
the outer `with` statement ... you see my point? we are dropping
powerful features in order to make JavaScript the toy we all think is
since ever
A while ago I discussed the 'with' trick on es-discuss (I don't remember
when, it was a message
Le 08/03/2013 22:19, Andrea Giammarchi a écrit :
This opens doors to debuggers (introspection) and APIs magic quite a lot.
If you want to write a debugger, use a debugger API [1] which is only
executed in privileged environments, no?
Debuggers are useful, but pierce encapsulation which is
Le 06/03/2013 23:31, Sam Tobin-Hochstadt a écrit :
On Wed, Mar 6, 2013 at 9:46 AM, Kevin Smith khs4...@gmail.com wrote:
(Referencing the module loaders proposal at
http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders)
1) Loaders have a strict flag which indicates whether code
Le 07/03/2013 13:19, Sam Tobin-Hochstadt a écrit :
On Mar 7, 2013 4:53 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 06/03/2013 23:31, Sam Tobin-Hochstadt a écrit :
On Wed, Mar 6, 2013 at 9:46 AM, Kevin Smith khs4...@gmail.com
mailto:khs4...@gmail.com wrote
Le 05/03/2013 00:31, Jason Orendorff a écrit :
On Sun, Mar 3, 2013 at 12:45 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
[2, 8, 7].forEach(function(e){
if(e === 8)
throw StopIteration;
This would be taking a piece of one
I agree on the need but forsee problems with parametrized equivalence
operator [1][2] like which comparator should be used for the union of 2
sets with different comparators?
The need for set intersection/union/minus/etc. feels more important than
the need to parametrized the comparator.
Le 05/03/2013 18:32, Jason Orendorff a écrit :
On Tue, Mar 5, 2013 at 5:42 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Currently, if one wants to do stop an iteration early, he/she has
to be done one of the following way:
1)
try{
[2, 8
Le 05/02/2013 16:29, David Bruant a écrit :
Le 05/02/2013 13:52, Sam Tobin-Hochstadt a écrit :
Second, it forces
the use of the shadow target pattern in any wrapper, doubling the
number of allocations required.
I don't understand why more shadow targets would be necessary than
with direct
Le 05/03/2013 17:37, Brendan Eich a écrit :
David Bruant wrote:
I'm happy of the outcome of the thread if .findIndex is introduced,
but I can't help wondering whether a new method is going to be
introduced every single time someone brings up a pattern that would
make good use of stopping
Hi,
One (minor) annoyance with forEach/map, etc. is that the enumeration
can't be stopped until all elements have been traversed which doesn't
suit every use case. One hack to stop the enumeration is to throw an
error but that requires to wrap the .forEach call in a try/catch block
which is
Le 03/03/2013 19:56, Bjoern Hoehrmann a écrit :
* David Bruant wrote:
One (minor) annoyance with forEach/map, etc. is that the enumeration
can't be stopped until all elements have been traversed which doesn't
suit every use case. One hack to stop the enumeration is to throw an
error
Le 03/03/2013 20:29, Brendan Eich a écrit :
If you want some or every and not forEach, they are there -- use them.
No exception required.
I've found myself multiple times in a situation where I needed the index
of the first element responding to some conditions. I solved it the
following way:
Le 02/03/2013 01:58, Rafael Weinstein a écrit :
On Sat, Feb 2, 2013 at 11:02 AM, Brendan Eich bren...@mozilla.com wrote:
David Bruant wrote:
Interestingly, revocable proxies require their creator to think to the
lifecycle of the object to the point where they know when the object
shouldn't
Le 02/03/2013 12:11, Kevin Gadd a écrit :
I don't understand how the requestAnimationFrame approach (to
registering periodic callbacks) applies to scenarios where you want
Weak References (for lifetime management) or to observe an object (for
notifications in response to actions by other
be a removeEventListener too.
David
Marius
On Sat, Mar 2, 2013 at 7:53 PM, Bill Frantz fra...@pwpconsult.com
mailto:fra...@pwpconsult.com wrote:
On 3/2/13 at 3:47 AM, bruan...@gmail.com
mailto:bruan...@gmail.com (David Bruant) wrote:
I won't say it's absolutely better than WeakRefs
Le 21/02/2013 19:16, Mark S. Miller a écrit :
On Thu, Feb 21, 2013 at 9:12 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 18/02/2013 23:29, Claus Reinke a écrit :
What I'd like to understand is why likely static scoping problems
should lead
Le 18/02/2013 23:29, Claus Reinke a écrit :
Out of curiosity, what does your favorite test coverage tool report
for the source below? And what does it report when you comment
out the directive?
:-p Ok, there are exceptions if your code depends on semantic changes
described in the third section
Le 20/02/2013 21:08, Kevin Reid a écrit :
On Wed, Feb 20, 2013 at 11:52 AM, Nathan Wall nathan.w...@live.com
mailto:nathan.w...@live.com wrote:
`Object.isFrozen` and `Object.isSealed` don't really seem that
helpful to me for the very reasons you've discussed: They don't
represent
Le 18/02/2013 11:10, Claus Reinke a écrit :
I'm looking forward to any recommendation you'd have to improve this
guide, specifically about the runtime errors where I said something
about 100% coverage test suite and I'm not entirely sure about that.
Talking about 100% coverage and catching
Le 18/02/2013 16:48, Claus Reinke a écrit :
Talking about 100% coverage and catching all errors is never a
good combination - even if you should have found an example of
where this works, it will be an exception.
There are a couple of things I'm sure of. For instance, direct eval
aside (eval
Hi,
I'd like to share a piece of documentation I've recently written [1].
It's a guide to help developers understand how they can transition to
strict mode and what they should be aware of while making this transition.
Differences between strict and non-strict are divided into 3 categories:
Le 16/02/2013 23:31, Allen Wirfs-Brock a écrit :
Will this not just shift the current complexity someplace else?
Well, it means that for 100% backwards compatibility, Object.isFrozen
would have to be something like:
1. Let state = obj.[[GetIntegrity]]();
2 If state is frozen return true;
3
Le 17/02/2013 00:58, Biju a écrit :
In most time when user want to search something in a text, he/she
wants to do a case insensitive search.
For example to filter items displayed in list on a page.
Also on other applications, say any word processor, or in page search
in Firefox, IE, Chrome etc.
Le 15/02/2013 11:03, Mariusz Nowak a écrit :
I've worked a lot with ECMAScript5 features in last two years, and I must say
I never found a good use case for Object.freeze/seal/preventExtensions, it
actually raised more issues than it actually helped (those few times when I
decided to use it).
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
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
/freeze/isSealed/isFrozen
traps
David
[1] https://mail.mozilla.org/pipermail/es-discuss/2013-February/028724.html
[2] http://wiki.ecmascript.org/doku.php?id=harmony:harmony#goals
[3] jsperf.com/object-seal-freeze/
[4] http://jsperf.com/object-seal-freeze/2
/be
David Bruant wrote:
Hi
Le 13/02/2013 20:36, Tom Van Cutsem a écrit :
Hi David,
I went a bit too far suggesting frozen objects could de-facto
disappear with proxies.
I'm still unclear on the need for specific
seal/freeze/isSealed/isFrozen traps
I think Allen and I reached consensus that we might do
Le 13/02/2013 21:56, Mark S. Miller a écrit :
On Wed, Feb 13, 2013 at 11:17 AM, Tom Van Cutsem tomvc...@gmail.com
mailto:tomvc...@gmail.com wrote:
2013/2/10 Mark Miller erig...@gmail.com mailto:erig...@gmail.com
How does this interact with Proxies[1]? I know the answer
Hi,
The main use case (correct me if I'm wrong) for freezing/sealing an
object is sharing an object to untrusted parties while preserving the
object integrity. There is also the tamper-proofing of objects everyone
has access to (Object.prototype in the browser)
In a world with proxies, it's
Le 12/02/2013 16:06, Andreas Rossberg a écrit :
On 10 February 2013 19:40, Mark Miller erig...@gmail.com wrote:
How does this interact with Proxies[1]? I know the answer probably starts
with whitelist, but let's spell it out in this context, and test it
against the 8 membrane transparency cases
Le 11/02/2013 00:53, Andrea Giammarchi a écrit :
We have transpilers for everything else, we need few better things
today and FirefoxOS knows it, as example ... I'd love to see
discussions about all Mozilla proposals for FirefoxOS and not always
some tedious syntax for classes discussion, you
Le 11/02/2013 00:53, Andrea Giammarchi a écrit :
involve as many developers as possible, rather than provide /already
decided internal decisions based in already decided internal
pools/ nobody ever heard about out there (public pools or it didn't
happen)
hmm... I had skipped that part
Le 10/02/2013 13:21, Alex Russell a écrit :
FWIW, there continue to be strong misgivings about the pythonesqe
design we have now, but Mozilla insists on the back of their shipping
implementation. Many feel that exceptions for control-flow are a
missdesign, myself included
I agree and also
Le 10/02/2013 16:21, David Bruant a écrit :
Le 10/02/2013 13:21, Alex Russell a écrit :
FWIW, there continue to be strong misgivings about the pythonesqe
design we have now, but Mozilla insists on the back of their shipping
implementation.
I have made a mistake in keeping that part
Le 10/02/2013 16:50, David Bruant a écrit :
Le 10/02/2013 16:21, David Bruant a écrit :
Many feel that exceptions for control-flow are a missdesign, myself
included
That's the only part I disagree with and my answer applied to.
s/disagree/agree
Le 10/02/2013 08:07, Brendan Eich a écrit :
Allen Wirfs-Brock wrote:
Note that the enumerable attribute really only affects for-in
enumeration (and Object.keys), neither of which enumerates symbols
anyway. That, means that the enumerable attribute really has has no
current meaning for symbol
Le 10/02/2013 17:16, Mark S. Miller a écrit :
I do not understand what is being proposed. When I try to imagine a
proposal starting from what has been said, I have not been able to
imagine something that works. But that's not a criticism. What is this
alternate privacy idea?
My understanding
I have continued my wanderings on that topic elsewhere. Sharing as food
for thought:
Le 10/02/2013 16:21, David Bruant a écrit :
idealworld
I initially thought that yield could be the sugar of endframe as
yield(value), but yield and return/throw are different. In the former
case, the frame
Le 10/02/2013 20:55, Oliver Hunt a écrit :
Just a couple of questions on this wonderous topic:
* how is 'e instanceof StopIteration' intended to work across multiple global
objects?
StopIteration has a special StopIteration [[Brand]] [1], so the
cross-global story shouldn't be a problem for
Le 09/02/2013 00:39, Claude Pache a écrit :
Since BC is not an issue, let's pick the semantic that is most conform to the existing
Ecmascript object model, and let's not invent a weird: true property
descriptor just because we think that __proto__ deserves one.
The goal is to standardise the
Le 07/02/2013 18:42, Andreas Rossberg a écrit :
On 7 February 2013 18:36, David Bruant bruan...@gmail.com wrote:
I hardly understand the benefit of an inconditionally-throwing setter over a
__proto__ as data property, but I'm fine with either.
Well, it _is_ a setter, and even one that modifies
Le 08/02/2013 19:35, Allen Wirfs-Brock a écrit :
On Feb 8, 2013, at 10:15 AM, Claude Pache wrote:
The magic is not in the form of the '__proto__' property of the
Object.prototype object, but in the action that its setter performs.
You're assuming it's a setter already, but that's not a given.
Le 08/02/2013 23:07, David Bruant a écrit :
*Any* solution in these constraints in acceptable. Accessor? data?
magic:true property? That's all the same. Backward-compat doesn't care.
I forgot to say that in my opinion, any JS dev in his/her right mind
would start any new script with:
use
Le 07/02/2013 12:58, Andreas Rossberg a écrit :
We intend to have both unique and private symbols. The only
difference between the two is that the latter are filtered from
certain reflective operations.
I have come to think that this distinction is backwards. It is
attributing something to
Le 07/02/2013 17:25, Rick Waldron a écrit :
## __proto__.
YK: We just need compatibility
LH: We need to just suck it up and standardize
:-)
YK/BE: Discussion re: interop with current implementations.
BE: (Review of latest changes to __proto__ in Firefox)
EA: Matches Safari
BE: __proto__
Le 07/02/2013 18:22, Andreas Rossberg a écrit :
On 7 February 2013 18:09, David Bruant bruan...@gmail.com wrote:
Speaking of proxies, what should happen in the following case (setter and
proxy from same realm):
var protoSetter = Object.getOwnPropertyDescriptor(Object.prototype,
'__proto__').set
Le 05/02/2013 12:20, Tom Van Cutsem a écrit :
2013/2/4 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Le 04/02/2013 22:41, David Bruant a écrit :
Le 04/02/2013 19:57, Tom Van Cutsem a écrit :
The post-trap could be cached and reused, but only
Le 04/02/2013 23:11, Brendan Eich a écrit :
Mark S. Miller wrote:
In any case, you may be right that this is a fatal flaw. You're
making a performance-based argument, and it is certainly premature
one way or the other to predict how these relative costs will balance
out. Let's wait till we
Le 05/02/2013 13:52, Sam Tobin-Hochstadt a écrit :
On Tue, Feb 5, 2013 at 7:03 AM, David Bruantbruan...@gmail.com wrote:
I like the current API better because it allows for a cleaner pairing of pre
and post-traps, including the ability to share private intermediate state
through closure
, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
[...]
This does indeed get rid of invariant checks while guaranteeing
the invariants anyway and apparently not losing expressiveness. Wow.
;)
Was this discussed during the January TC39 meeting? Do
Le 04/02/2013 19:57, Tom Van Cutsem a écrit :
The post-trap could be cached and reused, but only if the
post-processing is independent of the specific arguments passed to the
intercepted operation.
Is there any harm in passing the trap arguments to the post-trap
function additionally to the
Le 04/02/2013 22:41, David Bruant a écrit :
Le 04/02/2013 19:57, Tom Van Cutsem a écrit :
The post-trap could be cached and reused, but only if the
post-processing is independent of the specific arguments passed to
the intercepted operation.
Is there any harm in passing the trap arguments
Le 03/02/2013 06:21, Brandon Benvie a écrit :
Some people would say that garbage collection is the most important
advancement in computer science in the last 20
yearshttp://www.codinghorror.com/blog/2009/01/die-you-gravy-sucking-pig-dog.html
Don't get me wrong, I didn't say nor didn't mean
Le 03/02/2013 12:08, Kevin Gadd a écrit :
On Sun, Feb 3, 2013 at 2:58 AM, David Bruant bruan...@gmail.com wrote:
Let's see how the example would be with weakrefs:
function Storage(){
var storage = []
return {
push(e){storage.push(makeWeakRef(e
Le 03/02/2013 01:59, Mark S. Miller a écrit :
Hi David, have you seen
https://github.com/tvcutsem/harmony-reflect/tree/master/notification ?
I remember seeing the announcement, but I must have forgotten about it.
My bad :-s
AFAICT, this provides the same flexibility as action proxies with
Le 02/02/2013 06:41, Nathan Wall a écrit :
David Bruant wrote:
David Bruant wrote:
Garbage collectors have evolved and cycles aren't an issue any
longer, weak
references or not.
Kevin Gadd wrote:
Cycles are absolutely an issue, specifically because JS applications
can interact
Hi,
Action proxies were born as a fork to notification proxies [1]. Both
were attempts to get rid of invariant checks which have some cost. It's
probably too late to bring such a change in the proxy design, but I have
given more thoughts to it, so I'll share it, in the hope it'll fuel
Le 02/02/2013 15:32, Tom Van Cutsem a écrit :
2013/2/2 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
About weakrefs, I've read a little bit [2][3] and I'm puzzled by
one thing: the return value of get is a strong reference, so if a
misbehaving component keeps this strong
Le 02/02/2013 20:02, Brendan Eich a écrit :
David Bruant wrote:
Interestingly, revocable proxies require their creator to think to
the lifecycle of the object to the point where they know when the
object shouldn't be used anymore by whoever they shared the proxy
with. I feel this is the exact
Le 31/01/2013 22:48, Kevin Gadd a écrit :
I ask this because the lack of weak references (or any suitable
substitute mechanism) comes up regularly when dealing with the
challenge of porting native apps to JavaScript, and it leads people to
consider extremely elaborate workarounds just to build
Le 01/02/2013 12:21, Kevin Gadd a écrit :
On Fri, Feb 1, 2013 at 2:06 AM, David Bruant bruan...@gmail.com wrote:
I don't understand the connection between the lack of weak references and
emulating a heap in a typed array.
For an algorithm that needs weak references to be correct, the only
way
Le 01/02/2013 22:02, Allen Wirfs-Brock a écrit :
Something like this can still be expressed in the current draft of ES6 as:
let p = Proxy(target, {
__proto__: VirtualObject.prototype,
get(key, receiver) {...},
set(key,value, reciever) {...}
});
This is ugly in its use of
Le 31/01/2013 16:10, François REMY a écrit :
Hi.
I must admit I didn't follow the whole thread about native element
proxyfication but when I left the consensus was that the native element should
not be proxied (ie: it would not work like Object.create(...) do not work for
them).
Just to
Le 31/01/2013 17:26, François REMY a écrit :
I think such a getter notation exists in WebIDL to formalize scars from
the past (like HTMLCollection) rather than to be used in new APIs
Yes and no. For exemple, something alike is envisionned to support custom
properties in CSS. Something like:
Le 31/01/2013 18:34, François REMY a écrit :
I think such a getter notation exists in WebIDL to formalize scars from
the past (like HTMLCollection) rather than to be used in new APIs
Yes and no. For exemple, something alike is envisionned to support custom
properties in CSS. Something like:
Le 31/01/2013 19:12, François REMY a écrit :
In this instance, it's possible for you as a polyfill author to replace
Element.prototype.style by your own getter which returns your special
proxy objects which do what you expect on property set.
For the style case, it's *maybe* possible to do so
the discussion with delay.
Thanks,
/Andreas
On 23 January 2013 10:49, David Bruant bruan...@gmail.com wrote:
[reordering]
Allen wrote:
We can understand the value of providing a clear method without talking
about GC at all.
I don't doubt there is a case to clear a data structure, but it can be
filled
Le 24/01/2013 09:52, Tom Van Cutsem a écrit :
2013/1/23 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Le 23/01/2013 09:38, Tom Van Cutsem a écrit :
3) because of JS's invoke = get + apply semantics, by
default a proxy always leaves the |this| value pointing
Le 22/01/2013 21:09, David Bruant a écrit :
Le 22/01/2013 20:05, Tom Van Cutsem a écrit :
Symbol-keyed indexing on the A face is distinct from symbol-keyed
indexing on the B face. But that's OK: it's the job of the membrane
to separate the A and the B face in the first place.
I don't think
;-) )?
If the cost can be reduced to a marginal difference with manual .clear,
I call the performance argument a tie too (leaving the debate to a
taste/feeling debate)
Le 23/01/2013 00:36, Allen Wirfs-Brock a écrit :
On Jan 22, 2013, at 2:35 PM, David Bruant wrote:
So, to find out if a weakmap is dead
Le 23/01/2013 09:38, Tom Van Cutsem a écrit :
3) because of JS's invoke = get + apply semantics, by default a
proxy always leaves the |this| value pointing at the proxy.
Looking only at 3), sometimes this is what you want, and sometimes it
isn't.
In which case would it be what you want?
The
Le 22/01/2013 07:31, Benoit Marchant a écrit :
Why can we express in a property descriptor the notion of writable,
configurable or enumerable but not private?
Because strings are forgeable, meaning that someone you may not trust
can read in your code or guess (maybe with low probability) the
Le 22/01/2013 11:47, Jason Orendorff a écrit :
On Mon, Jan 21, 2013 at 6:04 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
[...] WeakMap.prototype.clear questions the property that was true
before its adoption (you can only modify a weakmap entry if you
have
Le 21/01/2013 22:31, Tom Van Cutsem a écrit :
Let's talk through Allen and Brandon's suggestion of auto-unwrapping
private symbol access on proxies.
If a membrane can intercept all exchanged private symbols I think this
could be made to work.
Agreed. Unfortunately, I think the condition (If a
Le 22/01/2013 15:19, Jason Orendorff a écrit :
On Tue, Jan 22, 2013 at 5:56 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 22/01/2013 11:47, Jason Orendorff a écrit :
On Mon, Jan 21, 2013 at 6:04 AM, David Bruant bruan...@gmail.com
mailto:bruan
Le 22/01/2013 16:02, Tom Van Cutsem a écrit :
2013/1/22 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Le 21/01/2013 22:31, Tom Van Cutsem a écrit :
Let's talk through Allen and Brandon's suggestion of
auto-unwrapping private symbol access on proxies
Le 22/01/2013 16:13, Tom Van Cutsem a écrit :
2013/1/22 Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com
We can probably fix the built-ins with some ad hoc language about
them automatically resolving proxies to the target as the this
value. Or perhaps we could
Le 21/01/2013 22:42, Allen Wirfs-Brock a écrit :
On Jan 21, 2013, at 12:25 PM, David Bruant wrote:
Le 21/01/2013 20:52, Allen Wirfs-Brock a écrit :
On Jan 21, 2013, at 11:36 AM, Rick Waldron wrote:
This is the reality check I can get behind—I'm hard pressed to come up with a
use case
[Merging a couple of relevant posts]
Le 22/01/2013 15:59, Jason Orendorff a écrit :
Now, the only thing that can differentiate both the native against
this version is performance I think. Allen seems to argue that a
native .clear would have better perf characteristics (related to
Le 22/01/2013 20:05, Tom Van Cutsem a écrit :
2013/1/22 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Just realizing now, but how does the membrane do the symbol
unwrapping if private symbols pierces it?
2 contexts A and B share a symbol, the symbol initially has to go
Le 22/01/2013 15:59, Jason Orendorff a écrit :
A) Are there more WeakMap applications that will want .clear() or
applications that will want .clear() not to exist? Offhand I would bet
on the former, by a landslide, but if you think otherwise, or if
there's some other reason to privilege
Thanks a lot for these explanations! (Answer below)
Le 22/01/2013 22:46, Jason Orendorff a écrit :
Having said all that, I bet we could hack around the worst-case
GC performance. It'll be a pain, but GC is like that sometimes.
What you said above about the current GC setup that
Le 21/01/2013 03:35, Allen Wirfs-Brock a écrit :
On Jan 20, 2013, at 5:42 PM, David Bruant wrote:
Le 20/01/2013 23:05, Allen Wirfs-Brock a écrit :
On Jan 20, 2013, at 11:12 AM, David Bruant wrote:
complicated was an expression. Either proxies don't work with
class instances, making them
301 - 400 of 1196 matches
Mail list logo
