Le 03/02/2012 23:26, John J Barton a écrit :
On Fri, Feb 3, 2012 at 1:08 PM, David Bruant bruan...@gmail.com wrote:
Le 03/02/2012 17:54, John J Barton a écrit :
iframes seem to be effective for the cases David outlined.
I can come up with more use cases ;-) Regardless of use cases iframes
Le 02/02/2012 15:34, Russell Leggett a écrit :
On Wed, Feb 1, 2012 at 5:41 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Hi,
I have claimed here a couple of times, that in a JavaScript
application
containing code from different parties, the first to run
Le 02/02/2012 16:19, Russell Leggett a écrit :
I was just contending that CSP should not be required to be able to
run first.
As I said above, CSP provides additional protection that I'm happy to
have, but as this thread is titled, How to ensure that your script
runs first in a webpage, that
Hi,
I have claimed here a couple of times, that in a JavaScript application
containing code from different parties, the first to run is the one that
is in position to make decisions about security of the overall
application (freezing the primordials for a defender or monkey-patching
them if
Le 29/01/2012 19:05, Peter van der Zee a écrit :
Why can't we define a JSON.clone() or .deepClone() which would only
clone properties that are primitives, object or array. If they are
(instanceof) array, copy index properties and length value and create
new array with that information. If
Le 28/01/2012 18:16, Brendan Eich a écrit :
I don't think we should change __proto__ unnecessarily from current
implementations, including making it an accessor. Neither JSC nor
SpiderMonkey does that.
We do need the ability to delete it, so it should live on
Object.prototype and be
Le 28/01/2012 09:28, Herby Vojčík a écrit :
The proposal for | cites these usage examples:
- Setting the prototype of a function to something other than
Function.prototype
let f = EnhancedFunctionPrototype | function () {}
- Parrallel constructor/instance prototype chains
let
Le 23/01/2012 17:25, Brendan Eich a écrit :
David Bruant mailto:bruan...@gmail.com
January 22, 2012 12:54 PM
I'm not sure to understand what you're calling /the/ key.
WeakMap.prototype, being itself a weakmap, does provide a covert
channel (since everyone has access to the same primordial
Hi,
SpiderMonkey implementation landed today. I was looking over the commit
[1] and had a question.
There is a test:
assertEq(Object.prototype.toString.call(new Map), [object Map]);
I can't see anything about it neither in the latest spec draft nor in
the wiki proposal. Is it how
Le 22/01/2012 20:16, Tab Atkins Jr. a écrit :
On Sun, Jan 22, 2012 at 10:28 AM, David Bruant bruan...@gmail.com wrote:
Hi,
In Firefox Aurora as well as in Chromium 18, running the following
-
var wm = new WeakMap();
var o = {};
Object.preventExtensions(wm);
wm.set(o, 1
Le 22/01/2012 21:11, Brendan Eich a écrit :
Herby Vojčík mailto:he...@mailbox.sk
January 22, 2012 11:42 AM
David Bruant wrote:
I agree that Object.preventExtensions is defined as preventing addition
of new properties. Likewise, Object.freeze and Object.seal only act on
object properties
Hi,
This is an attempt to list and discuss how threats of a mutable
__proto__ can be prevented and how it is different in the data and
accessor property cases.
## One frame
Assuming code from 2 parties are running in the same frame (one set of
built-ins)
-
var o =
Le 20/01/2012 00:54, Brendan Eich a écrit :
David Bruant mailto:bruan...@gmail.com
January 19, 2012 1:15 AM
Le 19/01/2012 02:27, Waldemar Horwat a écrit :
Brendan: Kill typeof null. Replace it with Ojbect.isObject?
What would be the semantics of this?
It was not obvious but the precedent
Le 20/01/2012 00:57, Brendan Eich a écrit :
David Bruant mailto:bruan...@gmail.com
January 19, 2012 1:43 AM
Every time I've been thinking of an issue like this, the solution
I've found was whoever runs first wins.
This is not relevant to the example I showed.
All in all, regardless of data
Le 19/01/2012 02:27, Waldemar Horwat a écrit :
Brendan: Kill typeof null. Replace it with Ojbect.isObject?
What would be the semantics of this?
--
Object.isObject(null); // false
Object.isObject({}); // true
// so far so good :-)
Object.isObject(function(){}) // ?
--
I'd like to
Le 19/01/2012 06:44, Brendan Eich a écrit :
Use __proto__ in object literals to do a put (assuming that a
__proto__ getter/setter was created in Object.prototype) instead of a
defineProperty? All modes or only nonstrict mode?
Allen: Make such use of __proto__ to be a synonym for |. If a | is
Le 17/01/2012 01:46, Kris Kowal a écrit :
On Mon, Jan 16, 2012 at 4:39 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
then the method should be called getOrSetIfNotThere(obj, def) 'cause get()
would mislead too much
I’ve been calling this method getset for about three years, hoping
Le 17/01/2012 01:53, Kris Kowal a écrit :
For what it’s worth, Python dictionaries have .get(key, default) and
.setdefault(key, default). The former is non-mutating. Its behavior
is also different depending on arguments length. If the default is
not passed, it will throw an exception. If a
Le 17/01/2012 21:38, Axel Rauschmayer a écrit :
More
material:
http://calculist.org/blog/2011/12/14/why-coroutines-wont-work-on-the-web/
... and a link to the proposal:
http://wiki.ecmascript.org/doku.php?id=harmony:generators
;-)
David
___
Le 16/01/2012 18:30, Nuno Job a écrit :
Hi guys,
I would like to make the case for better native XML support in ES5:
This is the most commented open issue on V8:
http://code.google.com/p/v8/issues/detail?id=235
Unfortunately people didn't agree on E4X and this makes the life of
developers
Hi,
I recently wrote some code using WeakMaps and the following pattern
keeps coming over and over:
-
var v = wm.get(o);
if(v === undefined){
v = someValue;
order.set(o, v);
}
// now, wn has a value for o (either it already did or it's been added)
// v === wm.get(o)
// play with v
[Specifying the Davids]
Le 16/01/2012 21:56, Mark S. Miller a écrit :
I like the idea of the two argument get as proposed by David [BRUANT].
(In fact, I like it so much that I thought I'd already specified it
that way ;).) David [HERMAN], I'm glad to see you got it right in your
suggestion
Le 16/01/2012 21:56, Mark S. Miller a écrit :
I like the idea of the two argument get as proposed by David. (In
fact, I like it so much that I thought I'd already specified it that
way ;).) David, I'm glad to see you got it right in your suggestion at
Le 16/01/2012 22:46, Mark S. Miller a écrit :
David and Axel, I don't get it. What's wrong with the get with the
optional default value, as specified by that text and as currently
implemented by FF?
This discussion started with me saying that var v = wm.get(o,
someValue); could be a shortcut
Hi,
I'm refering to Allen's writing at [1]:
The basic idea is that the properties prototype object are shared
parts of all of inheriting child object. Modifying such a shared part
by a child, introduces a local change that is visible to that child
(and its children) so this requires creation
Le 15/01/2012 20:21, Allen Wirfs-Brock a écrit :
On Jan 15, 2012, at 8:10 AM, David Bruant wrote:
Hi,
I'm refering to Allen's writing at [1]:
The basic idea is that the properties prototype object are shared
parts of all of inheriting child object. Modifying such a shared part
by a child
Le 15/01/2012 21:23, David Bruant a écrit :
-
function C(){
this.length = 3;
}
function f(a,b){}
C.prototype = f;
var c = new C();
console.log(c.length);
-
For this code, ECMAScript 5 says:
When doing new C(), |this| is assigned C.prototype which is the
function f
Le 15/01/2012 21:23, David Bruant a écrit :
-
function C(){
this.length = 3;
}
function f(a,b){}
C.prototype = f;
var c = new C();
console.log(c.length);
-
For this code, ECMAScript 5 says:
When doing new C(), |this| is assigned C.prototype which is the
function f
Le 14/01/2012 03:09, Tab Atkins Jr. a écrit :
On Fri, Jan 13, 2012 at 5:08 PM, David Bruant bruan...@gmail.com wrote:
Le 14/01/2012 01:57, Tab Atkins Jr. a écrit :
In the direct proxies proposal at
http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies,
there's the following line
Le 13/01/2012 19:15, Brendan Eich a écrit :
Lasse Reichstein:
It might be changed if there was an actual advantage for the
programmers in using strict mode, which there hasn't been
I heard some got burnt by a missing var [1]. Strict mode and a bit of
testing could have prevented this blog post
Le 14/01/2012 01:57, Tab Atkins Jr. a écrit :
In the direct proxies proposal at
http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies,
there's the following line:
get:
* Invariant checks:
* if property exists on target as a data property, updates the
target’s property with the
Le 11/01/2012 19:10, John J Barton a écrit :
The blog post
http://yehudakatz.com/2012/01/10/javascript-needs-blocks/ makes the
case for blocks that act like functions when passed as arguments but
have loop-up rules more like nested blocks.
Of course these are called 'block lambdas', and I
Le 11/01/2012 22:42, John J Barton a écrit :
On Wed, Jan 11, 2012 at 1:04 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
From your e-mail, it seems granted that more developers
interested is a good thing. I can't really say whether I agree or
not. So I guess
Le 09/01/2012 06:29, Brendan Eich a écrit :
On Jan 8, 2012, at 7:20 PM, John J Barton wrote:
On Sun, Jan 8, 2012 at 3:35 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Firebug uses a library bind a lot, and we continually struggled
with the memoization
Le 08/01/2012 19:47, John J Barton a écrit :
(...)
window.addEventListener('load', boundOnLoad, false);
...
window.removeEventListener('load', boundOnLoad, false);
The JS method 1) must be bound to the correct object 2) be
reference-able for the removeEventListener.
This combination
Hi,
I have some feedback on the strawman in its current form.
First, a cosmetic one, at 4. is written ...(FF already acts this way,
so my previous message was wrong in claiming that Object.create(null)
fails to avoid this platform on all non-IE browsers.). I think this is
a left-over from a
at 11:01 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Hi Andrea,
It seems that what you want can be implemented as a library [1]
(actually you did it as well in your blog post). In this gist, a
cache is used. In a nutshell, it is a '(function, object
Le 06/01/2012 06:03, Mark S. Miller a écrit :
Such a built in memoization, whether by boundTo or this enhancement to
bind itself, creates a fatal ambient communications channel.
// initSES initialization, freezing all built in primordials other
than the true global
// load Alice as
these conditions. What is the benefit of a native implementation
rather than an WeakMap based polyfill?
David
[1] http://code.google.com/p/es-lab/source/browse/trunk/src/ses/WeakMap.js
br
On Fri, Jan 6, 2012 at 10:27 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 05/01
Le 06/01/2012 11:20, Andrea Giammarchi a écrit :
On Fri, Jan 6, 2012 at 10:50 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Your proposal won't be implemented in older browsers. Actually, it
is very likely that your proposal would be implemented in browsers
Le 06/01/2012 12:23, Andrea Giammarchi a écrit :
it doesn't ... as soon as you release the reference to o no leaks
persists but of course until you keep o on hold those unique callbacks
cannot be released ...
If you're telling me that keeping only one of the object or the function
alive but
Le 06/01/2012 12:51, Andrea Giammarchi a écrit :
unreachable without reference count? do you have an example different
from a private scope object that is reachable from that scope so I
would not call it unreachable?
I'm not sure I understand your question.
In IE6 (7? 8?), written naively,
Le 06/01/2012 16:54, Andrea Giammarchi a écrit :
there is no security issue ... it's meant like that plus what Mark did
not think about, is that if I use
(function () {
function callback() {}
var object = {};
window.addEventListener(no way, object.boundTo(callback), false);
//
Le 06/01/2012 17:43, Mark S. Miller a écrit :
On Fri, Jan 6, 2012 at 8:31 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 06/01/2012 06:03, Mark S. Miller a écrit :
Such a built in memoization, whether by boundTo or this
enhancement to bind itself
Hi Andrea,
It seems that what you want can be implemented as a library [1]
(actually you did it as well in your blog post). In this gist, a cache
is used. In a nutshell, it is a '(function, object) - boundFunction'
mapping. I used 2 levels of WeakMaps to achieve this.
I don't think a native
Le 01/01/2012 06:12, John J Barton a écrit :
On Sat, Dec 31, 2011 at 7:53 PM, Axel Rauschmayer a...@rauschma.de
mailto:a...@rauschma.de wrote:
1. Checking whether a variable has been declared.
Problematic: verbose and conflated with checking for a
declared variable having
Le 30/12/2011 02:28, John J Barton a écrit :
On Thu, Dec 29, 2011 at 5:11 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 30/12/2011 01:00, Lasse Reichstein a écrit :
On Thu, Dec 29, 2011 at 8:41 PM, Mark S. Miller
erig...@google.com mailto:erig
Le 30/12/2011 17:07, Russell Leggett a écrit :
On Fri, Dec 30, 2011 at 6:53 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 30/12/2011 02:28, John J Barton a écrit :
On Thu, Dec 29, 2011 at 5:11 PM, David Bruant bruan...@gmail.com
mailto:bruan
Le 30/12/2011 18:05, John J Barton a écrit :
On Fri, Dec 30, 2011 at 3:53 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 30/12/2011 02:28, John J Barton a écrit :
On Thu, Dec 29, 2011 at 5:11 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com
Le 29/12/2011 03:04, Mark S. Miller a écrit :
Darn. I completely missed that. No easy fix comes to mind. Suggestions?
I think '__proto__' in object literals should work like any property.
The ES.next proto operator [1] creates a standard alternative to using
__proto__ in object literal.
As the
Le 29/12/2011 12:38, Lasse Reichstein a écrit :
There is one side-effect to defining __proto__ using a getter/setter
property. You can extract the setter and store it for later, allowing
you to change the prototype of objects after someone else deleted the
__proto__ property.
That means that
Le 29/12/2011 05:08, Mark S. Miller a écrit :
On Wed, Dec 28, 2011 at 6:48 PM, Mark S. Miller erig...@google.com
mailto:erig...@google.com wrote:
[...]
For example, regarding sorting, leaving aside sparseness, I
suspect our shared model is that any sort algorithm implementation
Le 29/12/2011 18:13, Allen Wirfs-Brock a écrit :
On Dec 29, 2011, at 4:58 AM, David Bruant wrote:
Le 29/12/2011 03:04, Mark S. Miller a écrit :
Darn. I completely missed that. No easy fix comes to mind. Suggestions?
I think '__proto__' in object literals should work like any property
Le 30/12/2011 01:00, Lasse Reichstein a écrit :
On Thu, Dec 29, 2011 at 8:41 PM, Mark S. Miller erig...@google.com wrote:
Hi Allen, that's very clever. But I don't think it is needed.
David is right about running first. I also don't have a proof, but
practically I'm sure that for JS as it is
Hi,
Maps [1] and WeakMaps [2] are very similar in their API. Since neither
proposal discusses how they should interact with each other, I was
wondering what is supposed to happen when trying to use the API of one
on the other.
-
var m = new Map();
var key = {};
m.set(key, 37);
Le 27/12/2011 19:14, Mark S. Miller a écrit :
On Tue, Dec 27, 2011 at 7:15 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Hi,
Maps [1] and WeakMaps [2] are very similar in their API. Since neither
proposal discusses how they should interact with each other
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
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
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
names
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
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
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
Le 22/12/2011 10:47, Andreas Rossberg a écrit :
I strongly believe that any ad-hoc behavioural distinction that we
need to introduce between plain and private property names indicates a
problem with the semantics of either private names or proxies (or JS
objects in general, which is the
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 21/12/2011 11:25, Andreas Rossberg a écrit :
Indeed. What do you think of the different alternative proposals
(especially regarding the ad-hoc complications you point out)?
I agree with your analysis that passing the public view of a private
name to traps is not a true reification. However,
Le 21/12/2011 13:47, Andreas Rossberg a écrit :
In particular, I don't consider the
above example a good idea in real code, with or sans proxies. You
shouldn't go off mutating arbitrary objects, and it won't work with
non-extensible objects anyway (at least that's what I gather as the
current
Le 21/12/2011 13:59, Andreas Rossberg a écrit :
On 21 December 2011 13:33, David Bruant bruan...@gmail.com wrote:
Le 21/12/2011 11:25, Andreas Rossberg a écrit :
In essence, you are introducing two separate types of private names,
but the distinction only is observable in situations
[off-list]
Le 20/12/2011 14:11, Tom Van Cutsem a écrit :
VirtualHandlers are for creating virtual objects (for instance, a
remote object proxy for which there is no real physical target object
acting as a backing store).
Speaking of which, I'm reading the PDF version Structure and
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
Le 20/12/2011 14:45, Andreas Rossberg a écrit :
On 17 December 2011 00:24, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
I used to think this way about private names and proxies, and argued
for this position. However, I was wrong and it's a bad idea. Here's
why:
You might want to implement
Le 20/12/2011 22:45, Jason Orendorff a écrit :
As I understand the current proposals, opt-in will be required for scripts
that
(...)
- need the top-level scope to be declarative,
rather than tied to the global object as in ES5;
Where is the proposal for this? I can't find it at
I did start a related thread a while ago [1].
Brendan's response [2] explained a few things:
Please read RFC 4329:
http://tools.ietf.org/html/rfc4329
There will be *at least* a ;version=6 parameter you can use, probably
with either application/javascript and application/ecmascript -- I have
Le 19/12/2011 11:03, Tom Van Cutsem a écrit :
With the new direct proxies API, there is potentially another solution
to combining proxies with private names:
private name property get/set could bypass the proxy entirely and be
forwarded unconditionally to the target, just like |typeof|,
Le 19/12/2011 11:03, Tom Van Cutsem a écrit :
(...)
Separate getPrivate/setPrivate traps would avoid this confusion:
(...)
One thing that is unsaid in the current proposal is whether private
names can be used with Object.defineProperty and
Object.getOwnPropertyDescriptor. I think that private
Le 18/12/2011 14:24, Herby Vojčík a écrit :
(...)
Le 17/12/2011 19:03, Herby Vojčík a écrit :
Hello,
I saw some concerns about security of name.public and possible leak of
correspondence between public and its name.
Just to clarify, there is no security issue with '.public'. What I
argued
Le 18/12/2011 14:43, Herby Vojčík a écrit :
Hello,
I've come with the idea how to let proxies forward private names
without compromising the private name and the value stored under it,
as well.
It is an interesting idea, but is there a use case associated with this
idea? As far as I'm
, but this discovery was a
bit surprising.
I don't know whether my or Herby's alternative proposals are the end
response, but I think the current interaction with proxies and private
names needs to be reconsidered.
David
Le 17/12/2011 14:24, David Bruant a écrit :
Hi,
Here is a proposal related
Le 17/12/2011 00:24, Sam Tobin-Hochstadt a écrit :
On Fri, Dec 16, 2011 at 6:09 PM, David Bruant bruan...@gmail.com wrote:
Requiring you to care in order to avoid leaking private names is incredibly
error-prone.
So is requiring you to care in order to avoid leaking the public -
private map
Hi,
Here is a proposal related to the discussion we've had in the other
thread. Gist: https://gist.github.com/1490167
# Introduction
We've seen in [the thread Are Private name and Weak Map the same
feature? and the Assoc
Le 12/12/2011 16:40, Tom Van Cutsem a écrit :
(...)
So in short I would prefer sensible defaults over error-throwing
missing fundamental traps.
I'd be interested in hearing others' thoughts about this.
In how they are defined and used, virtual handlers are very much like
the previous proxy
Le 17/12/2011 19:03, Herby Vojčík a écrit :
Hello,
I saw some concerns about security of name.public and possible leak of
correspondence between public and its name.
Just to clarify, there is no security issue with '.public'. What I
argued for is that it does not bring more security than being
Le 17/12/2011 22:37, David Herman a écrit :
On Dec 17, 2011, at 4:04 AM, David Bruant wrote:
I propose to accept that o[n] may disclose 'n' if 'o' is a proxy.
This is just a non-starter. Then you can't use private names as private names.
I have read a lot of code that I have written myself
Hi,
I couldn't post on es-discuss yesterday, so I rewrote my message and
posted it on github [1]. Here is the markdown source:
# PART 1: The same feature?
When looked abstractly, both private name and weak maps propose an
equivalent feature: a mapping between 2 unforgeable references and a
There is a paragraph in the original e-mail that I forgot. Adding it below:
Le 16/12/2011 12:19, David Bruant a écrit :
Hi,
I couldn't post on es-discuss yesterday, so I rewrote my message and
posted it on github [1]. Here is the markdown source:
# PART 1: The same feature?
When looked
Le 15/12/2011 23:38, John J Barton a écrit :
On Thu, Dec 15, 2011 at 10:58 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Classless solutions need a compelling solution to this issue,
that is, an operation on a list of vanilla objects that yields a
class
Le 16/12/2011 18:18, Brendan Eich a écrit :
We are not giv[ing] up on private names -- you are really just talking a
bit too autodidactically here, frankly.
Indeed. What I meant was I do not mean that private names should be
given up. French does not have a passive form (or at least it's rarely
Le 16/12/2011 20:58, Brendan Eich a écrit :
From: David Bruant bruan...@gmail.com
Let's say we have two attenuators (proxies which reduce your authority over
a given object) constructors we'd like to compose: makeAttenuated1 and
makeAttenuated2
-
// assuming we have an object 'o
My answer is pretty much the same than the previous message
Le 16/12/2011 21:03, David Herman a écrit :
On Dec 16, 2011, at 11:52 AM, David Bruant wrote:
However, I have questions and concerns about the public counterpart.
Why does it exists?
It exists to prevent unintentionally leaking
Le 16/12/2011 22:03, Brendan Eich a écrit :
From: David Bruant bruan...@gmail.com
** if I trust a proxy, I share a:
Stop right there. You don't know whether another object passed to you is a
proxy or not. You cannot tell, in general. Nor should you have to care!
I made a mistake when I
Hi,
I have recently been writing some code. I have not had the need for a
proxy argument, but found a very close pattern that I thought would
benefit from a proxy argument
Here is a gist ( https://gist.github.com/1466999 ) with an example of
the pattern.
_Analysis:_
The
Le 07/12/2011 21:21, Tom Van Cutsem a écrit :
2011/12/6 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
All traps are optional. If missing (more precisely, if
handler[trapName] returns undefined), the proxy defaults to forwarding
the intercepted operation to its target
Hi,
All traps are optional. If missing (more precisely, if
handler[trapName] returns undefined), the proxy defaults to forwarding
the intercepted operation to its target object. [1]
Proxy({}, {get:undefined}).someProperty;
In this case, the description says that the operation is forwarded. I
second argument in the h function is very likely to be a bug
and I would be thankful to the language to warn me about it.
David
On Tue, Dec 6, 2011 at 11:13 PM, David Bruant bruan...@gmail.com wrote:
Hi,
All traps are optional. If missing (more precisely, if
handler[trapName] returns
Le 01/12/2011 08:47, Andrea Giammarchi a écrit :
Let's say this is an attempt to bring some new, easy to implement,
method for the native Object.prototype
Specially about forEach, the most used Array.prototype method out there,
That's quite an ambitious statement. I use forEach, but I think I
Le 30/11/2011 06:56, Allen Wirfs-Brock a écrit :
On Nov 30, 2011, at 10:24 AM, David Bruant wrote:
Le 29/11/2011 23:07, Allen Wirfs-Brock a écrit :
...
Objects serve as one of our primary abstraction mechanisms (the other is
functions and function closures have similar allocation issues
Le 29/11/2011 21:24, Mark S. Miller a écrit :
On Tue, Nov 29, 2011 at 11:03 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 29/11/2011 19:05, Mark S. Miller a écrit :
On Tue, Nov 29, 2011 at 10:01 AM, David Bruant
bruan...@gmail.com mailto:bruan
Le 29/11/2011 23:07, Allen Wirfs-Brock a écrit :
On Nov 30, 2011, at 8:15 AM, David Bruant wrote:
Avoiding an extra allocation is the only worry for this last point.
Very much like Tom worried about mirror allocation at
https://mail.mozilla.org/pipermail/es-discuss/2011-November/018734.html
Le 28/11/2011 01:07, Allen Wirfs-Brock a écrit :
On Nov 26, 2011, at 11:52 AM, David Bruant wrote:
Le 24/11/2011 22:29, Tom Van Cutsem a écrit :
2011/11/24 Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com
If we are going to have a @reflection module
Hi,
The current proposal for object extension [1] works like the following
(quoting the wiki):
-
obj.{a:1,b:2,c:3};
// is equivalent to
Object.defineProperties(obj, {
a: {value: 1, enumerable: true, writable: true, configurable: true},
b: {value: 2, enumerable: true, writable: true,
801 - 900 of 1196 matches
Mail list logo
