Le 22/12/2011 13:20, Tom Van Cutsem a écrit :
(...)
Having also just read about the different use cases of private names
versus just unique names, it would make a lot of sense to me if we
would separate these two (either via a flag or via different
constructors):
- private names: invisible
2011/12/22 Tom Van Cutsem tomvc...@gmail.com:
At first, I shared Andreas's concern about introducing a flag in feature X
that only seems to affect a superficially unrelated feature Y.
However, having skimmed the private names page, I stumbled upon a section
that seems to want to introduce
Le 26/12/2011 15:56, Erik Corry a écrit :
2011/12/22 Tom Van Cutsem tomvc...@gmail.com:
At first, I shared Andreas's concern about introducing a flag in feature X
that only seems to affect a superficially unrelated feature Y.
However, having skimmed the private names page, I stumbled upon a
2011/12/26 David Bruant bruan...@gmail.com:
Le 26/12/2011 15:56, Erik Corry a écrit :
2011/12/22 Tom Van Cutsem tomvc...@gmail.com:
At first, I shared Andreas's concern about introducing a flag in feature X
that only seems to affect a superficially unrelated feature Y.
However, having
Le 26/12/2011 16:37, Erik Corry a écrit :
2011/12/26 David Bruant bruan...@gmail.com:
Le 26/12/2011 15:56, Erik Corry a écrit :
I don't see how you need anything new in the language to support unique
names.
var newUniqueName = (function() {
var counter = 0;
return function () {
Le 26/12/2011 17:27, Erik Corry a écrit :
2011/12/26 David Bruant bruan...@gmail.com:
Le 26/12/2011 16:37, Erik Corry a écrit :
2011/12/26 David Bruant bruan...@gmail.com:
Le 26/12/2011 15:56, Erik Corry a écrit :
I don't see how you need anything new in the language to support unique
Le 26/12/2011 14:40, David Bruant a écrit :
(...)
I've given more thought to this idea.
For a second, let's imagine we have 2 independent flags: visible (or
reflectable) and trapped. It would make 4 cases:
1) visible trapped
2) invisible trapped
3) visible untrapped
4) invisible
On Mon, Dec 26, 2011 at 7:54 AM, David Bruant bruan...@gmail.com wrote:
On a side note, I have seen a talk where someone mentionned that the
use the same JavaScript in server and client was partially bullshit,
because Node has support for some ES5 features that legacy web browsers
can't even
Oh, and we prevent access to all property names that end in __ (double
underbar), which again is probably not what that speaker had in mind.
On Mon, Dec 26, 2011 at 10:40 AM, Mark S. Miller erig...@google.com wrote:
On Mon, Dec 26, 2011 at 7:54 AM, David Bruant bruan...@gmail.com wrote:
On a
On Mon, Dec 26, 2011 at 8:27 AM, Erik Corry erik.co...@gmail.com wrote:
On a side note, I have seen a talk where someone mentionned that the
use the same JavaScript in server and client was partially bullshit,
because Node has support for some ES5 features that legacy web browsers
can't
Le 26/12/2011 19:40, Mark S. Miller a écrit :
On Mon, Dec 26, 2011 at 7:54 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
On a side note, I have seen a talk where someone mentionned that the
use the same JavaScript in server and client was partially bullshit,
For another the modules infrastructure that you have on
node is (for good reasons, I suspect) completely different to the
infrastructure available on the client, which makes a difference to
the way you structure your program.
I’ve heard that claim many times, but I have yet to see compelling
On Mon, Dec 26, 2011 at 11:08 AM, David Bruant bruan...@gmail.com wrote:
Le 26/12/2011 19:40, Mark S. Miller a écrit :
[...]
A pointer would be appreciated, thanks. Caja has a rather complete
emulation of ES5 that runs in legacy browsers going back to IE6. [...]
You can try out our
At first, I shared Andreas's concern about introducing a flag in feature X
that only seems to affect a superficially unrelated feature Y.
However, having skimmed the private names page, I stumbled upon a section
that seems to want to introduce precisely such a flag for different but
related
Le 22/12/2011 13:20, Tom Van Cutsem a écrit :
At first, I shared Andreas's concern about introducing a flag in
feature X that only seems to affect a superficially unrelated feature Y.
However, having skimmed the private names page, I stumbled upon a
section that seems to want to introduce
2011/12/22 David Bruant bruan...@gmail.com
Le 22/12/2011 13:20, Tom Van Cutsem a écrit :
Having also just read about the different use cases of private names
versus just unique names,
Can you give a link to or describe these uses cases? It will make easier
(at least to me) understanding
Le 22/12/2011 17:15, Tom Van Cutsem a écrit :
2011/12/22 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Le 22/12/2011 13:20, Tom Van Cutsem a écrit :
Having also just read about the different use cases of private
names
versus just unique names,
Can you give
Le 17/12/2011 14:24, David Bruant a écrit :
(...)
# Proposal
What about a 'trapped' boolean in the private name constructor?
It would work this way:
`JavaScript
var n = new Name(false); // don't trap when used is a proxy
var p = new Proxy({}, maliciousHandler);
p[n] = 21; // the
Hi,
Here is a code snippet using the current direct proxy proposal and the
private name proposals:
-
var name = new Name();
var target = {};
var p = new Proxy(target, {/* all default transparent forwarding traps
*/});
target[name] = 1;
p[name] = 2;
// target[name] === 1
//
19 matches
Mail list logo
