Le 18/07/2012 06:32, Jeff Walden a écrit :
On 07/17/2012 11:37 AM, Brendan Eich wrote:
That's nice but it doesn't address the argument that ECMA-262, not a certain
implementation, should not expose a usable setter at all (never mind wrapped
and monitored).
You'd be on stronger ground if you
Le 18/07/2012 11:35, Andreas Rossberg a écrit :
On 18 July 2012 09:59, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Im my humble opinion, making Object.prototype.__proto__
configurable (and actually deletable) [1] should be a much highier
priority than choosing
Le 05/07/2012 11:08, Patrik Stutz a écrit :
I've read the articles you linked to and still think that 'delay'
would be a great idea! I think this
http://calculist.org/blog/2011/12/14/why-coroutines-wont-work-on-the-web/ post
is wrong in many things. In my opinion, coroutines would be even
Le 05/07/2012 17:19, Patrik Stutz a écrit :
BUT: interestingly, the import keyword also seems to be synchronous.
So, I think behind the scenes there still would have to be something
like a delay function to make it non-blocking. Or am I missing
something?
The 'import' keyword is synchronous,
Le 27/06/2012 10:31, Brendan Eich a écrit :
David Bruant wrote:
Le 26/06/2012 16:44, David Bruant a écrit :
Also relevant to this thread, post on the same topic by Isaacs
(node.js lead) : http://blog.izs.me/post/25906678790/on-es-6-modules
Furthermore, |let| already gives us destructuring
Le 27/06/2012 11:09, Brendan Eich a écrit :
David Bruant wrote:
Le 27/06/2012 10:31, Brendan Eich a écrit :
David Bruant wrote:
Le 26/06/2012 16:44, David Bruant a écrit :
Also relevant to this thread, post on the same topic by Isaacs
(node.js lead) : http://blog.izs.me/post/25906678790
'this'. I'm shooting myself in the foot here, but
it's worth noting that it would be an easy change (like a couple of
characters) to make jQuery as usable today and potentially directly
compatible with the ES module syntax.
Le 27/06/2012 11:48, Brendan Eich a écrit :
David Bruant wrote:
Import
Also relevant to this thread, post on the same topic by Isaacs (node.js
lead) : http://blog.izs.me/post/25906678790/on-es-6-modules
David
Le 26/06/2012 06:24, James Burke a écrit :
Posted here:
http://tagneto.blogspot.ca/2012/06/es-modules-suggestions-for-improvement.html
Some of it is a
Le 26/06/2012 16:44, David Bruant a écrit :
Also relevant to this thread, post on the same topic by Isaacs
(node.js lead) : http://blog.izs.me/post/25906678790/on-es-6-modules
Furthermore, |let| already gives us destructuring assignment. If a
module exports a bunch of items, and we want several
Le 25/06/2012 17:36, Allen Wirfs-Brock a écrit :
On Jun 22, 2012, at 11:01 AM, David Bruant wrote:
...
There is a potential security issue. From the wiki [1] (in the case
where the instance is a proxy trapping on instanceof): Security issue:
the handler is given a reference to the function
Le 25/06/2012 17:49, Allen Wirfs-Brock a écrit :
On Jun 24, 2012, at 5:51 AM, Brendan Eich wrote:
David Bruant wrote:
Instead of adding a new [[instanceofHint]] internal property, maybe the
[[NativeBrand]] could be reused.
+1 on that, which suggests [[NativeBrandMatch]] instead
Le 24/06/2012 14:51, Brendan Eich a écrit :
David Bruant wrote:
Instead of adding a new [[instanceofHint]] internal property, maybe the
[[NativeBrand]] could be reused.
+1 on that, which suggests [[NativeBrandMatch]] instead of
[[InstanceofMatch]].
Your proposal is more general but I think
Le 22/06/2012 18:13, Allen Wirfs-Brock a écrit :
I'm going to try to move the discussion of this issue to es-discuss
via a separate message as it is mostly about Proxy design. (bcc'ing
public-script-coord)
the start of this subthread is the following which identifies that
historically the
What about a more generic operator that would be able to silently absorb
any error?
let greedy = obj.hints?.greedy;
would become:
let greedy = silent obj.hints.greedy;
The semantic would be exactly the same.
The syntax is up to debate. Specifically, it would be nice to be able to
an or statement would be cumbersome since there is already 'undefined'
as implicit or-value.
But why not.
David
On Tue, Jun 19, 2012 at 3:00 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
What about a more generic operator that would be able to silently
absorb
Le 19/06/2012 14:11, Alex Russell a écrit :
On Jun 11, 2012, at 11:46 AM, David Bruant wrote:
Hi,
Le 11/06/2012 12:30, Hemanth H.M a écrit :
[].forEach.call(NodeList,function(elm) {}) why that? Why not treat it like an
[] ?
I've written a section on MDN specifically a while ago to answer
Le 19/06/2012 18:21, Erik Arvidsson a écrit :
On Tue, Jun 19, 2012 at 6:42 AM, 程劭非 csf...@gmail.com wrote:
I guess we can try to push Web IDL to do this.
WebIDL provides [ArrayClass] and DOM4 make NodeLists ArrayClass. This
means that NodeLists have Array.prototype on its prototype chain.
Le 15/06/2012 21:27, Brandon Benvie a écrit :
Currently there's no way to have a data property that is writable by
some but not all.
My heartbeat reaction to this first sentence is: is it a use case anyway?
This can't even really be achieved with accessors or proxies directly.
Rather, the
Le 14/06/2012 11:42, Hemanth H.M a écrit :
Was just wondering if something like *Object.inspect(myObj) *would
give all the attributes of that particular object.
In ES5, there are Object.getOwnPropertyNames as well as
Object.getOwnPropertyDescriptor. These are the lowest-level constructs
you
Le 14/06/2012 12:56, Mark S. Miller a écrit :
On Thu, Jun 14, 2012 at 6:00 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Hi again,
here few inconsistencies I have found with latest version, for Mac, of
these two dev/channel browsers.
Map#set(key, value)
Aurora: Map#set()
Le 12/06/2012 15:27, Hemanth H.M a écrit :
Would something like :
|obj[prop] ||= NewProp|
be useful?
ahah, I asked the same question very recently [1]. Answer by Brendan
Eich [2].
I definitely agree that default arguments are a decent alternative. I
can't recall examples where it wouldn't be
Le 12/06/2012 16:19, Hemanth H.M a écrit :
Would it be useful to have something like sum[value] = sum.get(value,
0) + 1
You can always do
sum[value] = (sum.get(value) || 0) + 1;
I think it's simple enough to justify not having an additional (and
potentially confusing) argument, but I'm
Le 12/06/2012 18:02, Tab Atkins Jr. a écrit :
On Tue, Jun 12, 2012 at 7:36 AM, David Bruantbruan...@gmail.com wrote:
Le 12/06/2012 16:19, Hemanth H.M a écrit :
Would it be useful to have something like sum[value] = sum.get(value, 0) + 1
You can always do
sum[value] = (sum.get(value) ||
Hi,
Le 11/06/2012 12:30, Hemanth H.M a écrit :
[].forEach.call(NodeList,function(elm) {}) why that? Why not treat it
like an [] ?
I've written a section on MDN specifically a while ago to answer that
very question:
Hi,
I'm wondering what's the point of posting just a video like this. Do you
have specific needs? Are there issues you want to discuss?
We all want sugar. I came to es-discuss as a developer (which I still
am) and I wish there was more sugar and that's in part what is being
discussed here on
Le 11/06/2012 14:56, Hemanth H.M a écrit :
Wow, that's interesting. When will that be implemented?
Depends on browsers. Good news is that you can polyfill it today! :-)
Actually, that could be a good fit for https://github.com/paulmillr/es6-shim
David
On Mon, Jun 11, 2012 at 5:59 PM, Rick
On Mon, Jun 11, 2012 at 6:48 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
http://productforums.google.com/forum/#!topic/docs/0hQWeOvCcHU
http://productforums.google.com/forum/#%21topic/docs/0hQWeOvCcHU
--
/'I am what I am because of who we all are'/
h3manth.com http
Le 08/06/2012 13:53, Christian Mayer a écrit :
Thanks for the quick answer!
Am 07.06.2012 20:28, schrieb Brendan Eich:
This is not a candidate for the core language standard, ECMA-262.
OK. If ECMA-262 is only about core and not the (default) library -
where could I ask then? Which body takes
Le 08/06/2012 16:02, Brendan Eich a écrit :
David Bruant wrote:
Indeed. Web technologies have not taken the XML turn a lot of people
expected 5-10 years ago.
I'd go further. XML failed. We founded the whatwg in 2004 (Mozilla,
Opera, Apple) because the w3c was chasing a utopian, replace
Le 29/05/2012 21:18, John J Barton a écrit :
On Tue, May 29, 2012 at 11:32 AM, Brendan Eichbren...@mozilla.org wrote:
John J Barton wrote:
This is one of those cases where a small delta creates a very large
negative effect.
Evidence?
If you look back on this thread you will see an example
Le 30/05/2012 15:24, Brendan Eich a écrit :
David Bruant wrote:
Additionally to JSON, I'd like to ask about if decisions have been
made for __proto__ in object literal notation.
That's part of the de-facto __proto__ standard, AFAIK.
I haven't seen it discussed in the meeting notes (though
Le 28/05/2012 01:37, John J Barton a écrit :
On Thu, May 24, 2012 at 11:10 AM, Brendan Eichbren...@mozilla.com wrote:
David Bruant wrote:
Once we're at it, for the sake of completeness there is probably no harm
in adding a Reflect.setPrototype at this point, is there?
There is, just
Le 26/05/2012 21:08, Brendan Eich a écrit :
David Bruant wrote:
Because max-min classes are inching towards consensus, I suggest the
that appropriate way to subclass the built-in constructors will be
via |class extends|. eg
class MyArray extends Array {
someMyArrayProtoMethod
Le 24/05/2012 20:10, Brendan Eich a écrit :
David Bruant wrote:
Thanks for the notes and complements :-)
Le 24/05/2012 04:43, Brendan Eich a écrit :
Rick Waldron wrote:
MM:
- From a security perspective, I'd like to move __proto__ out of
annex B and into normative body
BE:
- If MS puts
Le 26/05/2012 13:53, Tom Van Cutsem a écrit :
Hi,
If __proto__ is getting standardized, I propose we adapt proxies to be
able to trap getPrototypeOf.
Why?
- with __proto__, stable prototypes are no longer an invariant. It's
awkward to make proxies go out of their way to maintain it still.
Le 26/05/2012 17:55, Allen Wirfs-Brock a écrit :
On May 26, 2012, at 2:37 AM, David Bruant wrote:
The use case of subclassing native constructors (just to clarify I'm
only talking about Array, Date, WeakMap, etc. Not DOM constructors)
is legitimate and has been raised and detailed in length
Le 24/05/2012 07:13, Brendan Eich a écrit :
Compilers do seem attractive, not only for ES6-prototyped to ES5, but
for even more advanced/experimental languages (LLJS, for example).
CoffeeScript is quite usable, too.
Source map makes this even easier and smoother. In his JSConf 2012
Thanks for the notes and complements :-)
Le 24/05/2012 04:43, Brendan Eich a écrit :
Rick Waldron wrote:
Triangle
Is capable of giving up private names
If people have __proto__ they will not use |.
I don't know who are people but I'm not one of them. | offered some
nice sugar with regard to
Le 10/05/2012 04:44, Mikeal Rogers a écrit :
The core problem is that people who work nearly full time on designing a
language are necessarily out of touch with people using it, and the people
using it are ill equipped to balance the priorities all all the parties
involved in designing it.
I
Le 10/05/2012 01:46, Axel Rauschmayer a écrit :
I’m seeing quite a bit of anti-TC39 sentiment out there and I don’t think it’s
fair. Some examples (paraphrasing):
- “TC39 doesn’t care about web developers and/or doesn’t understand web
development.”
- “TC39 ignores what the people want and
Le 07/05/2012 13:06, Andreas Rossberg a écrit :
On 4 May 2012 06:42, Allen Wirfs-Brockal...@wirfs-brock.com wrote:
When a global environment is initialized it can be configured so var and
function declaration bindings go into either the Global Object environment or
the Top Lex environment
Le 04/05/2012 18:37, Allen Wirfs-Brock a écrit :
On May 4, 2012, at 8:33 AM, David Bruant wrote:
Hi,
Le 04/05/2012 06:42, Allen Wirfs-Brock a écrit :
Common ways to configure the global environment:
Browser compat:
ES5 built-in global bindings replicated on the global object
Hi,
Le 04/05/2012 06:42, Allen Wirfs-Brock a écrit :
Goals:
Duplicate current browser global semantics
Existing ES5 built-ins are properties of the global object
Global Function and Var declarations create properties of the global
object
Ad hoc semantics
Le 19/04/2012 01:00, Brendan Eich a écrit :
David Bruant wrote:
var p = Proxy(target, {});
p(); // throws exception because the proxy is reported as not
having
// a @call property
In the get trap of the proxy, the @call private name is transformed into
its public
Le 19/04/2012 01:54, Brandon Benvie a écrit :
(or you simply don't trap the access, which is the route for
[[prototype]], [[instanceof]], etc which now makes even more sense to
me in light of this)
Not trapping seems like a valid option [1]. The rationale for the
.public counterpart in the
Le 19/04/2012 16:55, Tom Van Cutsem a écrit :
I still like the idea of distinguishing private from unique names,
where private = invisible via reflection proxies and unique =
visible via reflection proxies (cf. the thread David linked to).
Additionally to this proposal, if the
Le 17/04/2012 22:44, Brendan Eich a écrit :
Brendan Eich wrote:
Irakli Gozalishvili wrote:
It would be amazing to have clojure like protocols in JS even
without `IFn`. I think it's very good feet and very useful in JS
where each library has it's own flavored API. I wrote more about it
here:
Le 17/04/2012 22:44, Brendan Eich a écrit :
Let there be private names @call and @construct (I'll spell them this
way to avoid tedious imports of const bindings from @std or another
built-in module).
Let Clause 15.3.5 include new non-configurable, non-writable
properties of function objects
Le 18/04/2012 17:14, Brendan Eich a écrit :
David Bruant wrote:
Change 11.2.3 Function Calls to use @call not [[Call]], passing
the /thisValue/ and /argList/ according to the
Function.prototype.call convention: (thisValue, ...argList).
@call as own property only or is it inherited as well
Le 18/04/2012 19:48, Brendan Eich a écrit :
Mainly the own-only restriction seems less-good compared to how, e.g.
proxy traps or accessors are found, via full prototype-based delegation.
I agree with your point.
However, I'd like to restate that interaction between proxies and
private names as
Hi,
Today, I came across a test on Firefox test suite [1]. This test
verifies that on the proxy, the traps gets called in the right order
according to the ES5 algorithm of Array.prototype.splice.
Seeing this test made me realize that as soon as proxy gets in the spec
and implemented in web
Le 13/04/2012 01:36, Brandon Benvie a écrit :
With Direct Proxies there's no such thing as a fully virtual object.
Virtualized objects can be achieved by just creating a new
empty/placeholder object with the desired invariants ([[prototype]],
[[class]], etc). This is all well and good except
Hi,
I am not part of TC39.
I do not really have any opinion on whether it's a good or bad idea, but
I have some questions (below):
Le 11/04/2012 20:11, Joey Schorr a écrit :
Greetings ES Discuss!
We (Joey Schorr and John Lenz, CCed) are some of the authors of the
source map specification
Le 11/04/2012 20:11, Joey Schorr a écrit :
Greetings ES Discuss!
We (Joey Schorr and John Lenz, CCed) are some of the authors of the
source map specification that is now implemented by WebKit and
Firefox, as well as a number of compilers (Closure Compiler, GWT and
soon CoffeeScript).
I have
Le 07/04/2012 00:57, Allen Wirfs-Brock a écrit :
On Apr 6, 2012, at 2:57 PM, Axel Rauschmayer wrote:
I was thinking about Allen's
class Sub extends mixin(Jane, Jack, Super) {
}
Which could have the following prototype chain.
Sub - Jane' - Jack' - Super.prototype
A method
Le 04/04/2012 02:41, Irakli Gozalishvili a écrit :
On Tuesday, 2012-04-03 at 14:07 , David Bruant wrote:
Le 03/04/2012 22:00, Irakli Gozalishvili a écrit :
Here is more or less what I have in mind:
https://gist.github.com/2295048
// class
var Point = {
(x, y) {
this.getX = { () { return x
Le 02/04/2012 17:59, Irakli Gozalishvili a écrit :
Hi David,
Your protected work reminds me a lot of what we did with `namespcase`
module in jetpack:
https://addons.mozilla.org/en-US/developers/docs/sdk/latest/packages/api-utils/namespace.html
Which I also blogged about some time ago:
Le 01/04/2012 13:38, Wes Garland a écrit :
In a similar vein, I would personally like to have
zero-cost-when-not-debugging assert() statements, and am hopeful that
statically-linked modules might lead the way.
It seems to me that what you're asking for is macros, isn't it?
I read hints here
Le 03/04/2012 17:12, John J Barton a écrit :
On Tue, Apr 3, 2012 at 7:03 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 01/04/2012 13:38, Wes Garland a écrit :
In a similar vein, I would personally like to have
zero-cost-when-not-debugging assert
Le 03/04/2012 17:00, Kris Kowal a écrit :
On Tue, Apr 3, 2012 at 1:49 AM, David Bruantbruan...@gmail.com wrote:
Le 02/04/2012 17:59, Irakli Gozalishvili a écrit :
I remember that one of your complaints about namespaces was that inheritance
was not supported. Do you think there is a workable
Le 03/04/2012 22:00, Irakli Gozalishvili a écrit :
Here is more or less what I have in mind: https://gist.github.com/2295048
// class
var Point = {
(x, y) {
this.getX = { () { return x; } }
this.getY = { () { return x; } }
}
toString() {
return '' + this.getX() + ',' +
Hi,
A while ago, I posted a challenge on es-discuss [1]. It was a challenge
related to code reuse, modularity and composition. There has been an
interesting suggestion [2] [3] which left me a bit unsatisfied since
relying on constructor arguments while it may not be always possible to
do that.
Le 30/03/2012 07:17, Peter Michaux a écrit :
I've worked on a generic Set polyfill. It is quite a simple task to
build one but determining if an object is in the set is O(n) with the
following has method.
Set.prototype.has = function(element) {
for (var i = 0, ilen =
I'm not sure I understand the reasonning here.
Introducing a new feature to shim another new feature? What about
implementators just implement the initial new feature?
In other words: would hash be of any use if Set, Map and WeakMaps (why
not WeakSets?) were deployed? Set/Map/WeakMap are already
Le 19/03/2012 23:12, Allen Wirfs-Brock a écrit :
On Mar 19, 2012, at 2:36 PM, David Bruant wrote:
Le 19/03/2012 21:10, Maël Nison a écrit :
Hi,
I'm 'upping' this discussion for two reasons :
- I didn't send any response before ! I didn't know that some parts of
V8 were self-hosted, so I'm
Le 10/03/2012 23:03, Brandon Benvie a écrit :
It's not really a security vulnerability on its own, but it does mean
that as of current it's impossible to prevent
executing JavaScript from being able to precisely determine under what
conditions its running in almost all cases without being able
Le 19/03/2012 21:10, Maël Nison a écrit :
Hi,
I'm 'upping' this discussion for two reasons :
- I didn't send any response before ! I didn't know that some parts of
V8 were self-hosted, so I'm glad to have learn that. Thanks. : )
- I've just read this article [1] on the web, and it reminds
Le 18/03/2012 02:06, Mark S. Miller a écrit :
http://www.infoq.com/presentations/Secure-Mashups-in-ECMAScript-5
Has some new material relevant to issue we discuss on this list. Enjoy!
The end of the talk is missing, isn't it?
What are the 2 other attacks?
I'd try to guess:
1) Assuming Bob
Le 17/03/2012 00:50, Jonas Höglund a écrit :
On Sat, 17 Mar 2012 00:18:48 +0100, David Bruant bruan...@gmail.com
wrote:
A Person knows one secret and has methods like .eat(), .walk()... There
is no method in the Person interface to reveal the secret either
directly or indirectly
Le 17/03/2012 00:36, John J Barton a écrit :
On Fri, Mar 16, 2012 at 4:18 PM, David Bruant bruan...@gmail.com wrote:
...
This is a piece of cake with Java's protected. It is much convoluted in
JavaScript. I think this kind of problem being hard to solve in
JavaScript is the reason why so many
Le 16/03/2012 17:53, Herby Vojčík a écrit :
And second, it is not a tragedy if such classes leak.
What do you mean exactly by leak. Like private name leaking?
David
___
es-discuss mailing list
es-discuss@mozilla.org
Hi,
I'll do a 2 parts answer. First, I'll answer the blog post, second, I'll
try to take a step back and discuss composition in JavaScript.
=== Part I ===
Le 16/03/2012 17:04, Kevin Smith a écrit :
Rather than abuse your inbox, I published this as a blog entry:
Le 16/03/2012 21:26, Kevin Smith a écrit :
Thanks, David.
First, I'd like to point out that in the blog post I'm putting on the
hat of a library author (I happen to be one, but that's beside the point).
One of the first conclusions that I come to (as a library author) is
that the idiom
Le 16/03/2012 23:00, Rick Waldron a écrit :
On Fri, Mar 16, 2012 at 5:12 PM, Domenic Denicola
dome...@domenicdenicola.com mailto:dome...@domenicdenicola.com wrote:
Just to contribute to this... er... fun-thread...
My team uses the closure pattern for our classes (i.e. no
Le 16/03/2012 23:12, Rick Waldron a écrit :
On Fri, Mar 16, 2012 at 6:04 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 16/03/2012 23:00, Rick Waldron a écrit :
On Fri, Mar 16, 2012 at 5:12 PM, Domenic Denicola
dome...@domenicdenicola.com
mailto:dome
Challenge at the bottom
Le 16/03/2012 23:34, John J Barton a écrit :
On Fri, Mar 16, 2012 at 3:04 PM, David Bruant bruan...@gmail.com wrote:
Unfortunately, methods on prototype require to have properties that are
public.
If you avoid prototype methods, all your attributes and private methods
Le 10/03/2012 23:03, Brandon Benvie a écrit :
I submitted this as a potential security vulnerability to the Chromium
bug list but it didn't seem to register there. It's not a
vulnerability in that it has an imminent impact on anything, but I
would still classify it as one because of the
Le 08/03/2012 13:02, Maël Nison a écrit :
Hi,
I'm just wondering why there is no mutable function with Javascript
arrays.
For exemple, if I want to remove every entry matching 42 from an
array, I will have to write something like :
var array = [ 0, 1, 42, 3, 4, 5, 42, 42, 42 ];
array =
Le 08/03/2012 18:02, Maël Nison a écrit :
Shouldn't native versions be more efficients ?
I heard V8 is on the path of self-hosting (writing standard functions in
JavaScript itself) as much as it can (can anyone confirm?).
It seems that in some cases, there is actually no benefit in writing in
Le 08/03/2012 18:27, Mike Samuel a écrit :
http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders mentions
a system module loader.
Has the behavior of the system module loader been speced at all?
If not, would it be worthwhile specifying that when it loads an http
or https URL, it does
Le 08/03/2012 18:42, Wes Garland a écrit :
What about native JSON loading?
How would this be different from XHR + JSON.parse() sugar?
I think it wouldn't. Loading rules applied for module loading would be
applied to JSON loading.
Are you proposing loading the JSON from the server as though
Le 07/03/2012 02:10, Brandon Benvie a écrit :
I start this coming from the standpoint of an honest question that I
don't know the answer to: is there a specific reason that objects
can't be callable in js? Aside from the that's just how the language
is answer, I was wondering if there's some
Le 03/03/2012 12:26, Axel Rauschmayer a écrit :
http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects
Quote: “We could extend this to allow the passing of an optional visibility
flag (defaults to false) to create(). [...] This would be useful for e.g.
modular monkey-patching.”
Le 26/02/2012 01:23, Geoffrey Sneddon a écrit :
On 13/02/12 17:55, Allen Wirfs-Brock wrote:
Let's try to get this back to concrete issues that I can incorporate
into a specification.
The current draft is at
Le 26/02/2012 17:10, Mark S. Miller a écrit :
On Sun, Feb 26, 2012 at 1:39 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Creating cross-context chains with Object.create has not been
discussed
I think and should be fine...
or not?
Given
Hi Jason,
Thanks for sharing this work.
Le 24/02/2012 19:43, Jason Orendorff a écrit :
I wrote a benchmark and tested an implementation of Tyler Close's
deterministic hash table against some conventional, non-deterministic
ones.
Tyler Close's table is faster, but it uses more memory.
For
Le 19/02/2012 09:33, Brendan Eich a écrit :
(...)
How is the BRS configured? Again, not via a pragma, and not by
imperative state update inside the language (mutating hidden BRS state
at a given program point could leave strings created before mutation
observably different from those created
Le 19/02/2012 22:57, Anne van Kesteren a écrit :
On Sun, 19 Feb 2012 21:29:48 +0100, David Bruant bruan...@gmail.com
wrote:
I think a CSP-like solution should be explored.
FWIW, the feedback on CORS (CSP-like) thus far has been that it's
quite hard to set up custom headers.
Do you have
Le 16/02/2012 03:32, Peter Seliger a écrit :
that looks like a wrap to me ... what's the connection with bind()
exactly?
Also not sure you are talking about dispatched Events (before,
around, after) or some other topic
Sorry for not having pointed it out clearly enough.
I'm
Le 14/02/2012 07:22, Erik Arvidsson a écrit :
On Mon, Feb 13, 2012 at 21:25, Jason Orendorff
jason.orendo...@gmail.com wrote:
Unless TC39 specifies otherwise, the enumeration order of Map and Set
will be arbitrary, it will certainly be inconsistent across browsers,
and it will most likely even
Le 14/02/2012 11:23, Andreas Rossberg a écrit :
On 14 February 2012 09:47, David Bruantbruan...@gmail.com wrote:
For instance, what if Firefox and Chrome disagree, but iPhone safari and
Android Webkit agree?
Also, some products (Node.js (V8), MongoDB (SpiderMonkey), etc.) rely only
on one JS
Le 14/02/2012 07:31, Mark S. Miller a écrit :
[+tjclose]
There are many benefits to determinism. E started with
non-deterministic iteration order, which opens a covert channel
hazard. I initially changed to deterministic order merely to plug this
leak. Having done so, I found it had many
Le 14/02/2012 19:28, Jason Orendorff a écrit :
On Tue, Feb 14, 2012 at 5:02 AM, David Bruant bruan...@gmail.com wrote:
To be sure, this is assuming that iteration order is fixed for a given
implementation. If order is not specified, then I don't see why that
should be required either
Le 12/02/2012 23:47, Brendan Eich a écrit :
Oliver Hunt wrote:
On Feb 12, 2012, at 11:28 AM, Brendan Eich wrote:
Heh, I knew that was coming. I'll amend to say of long standing
after implementations :-P.
I still have a gut feeling that someone is going to take advantage
of the setter for
Le 10/02/2012 09:23, Gavin Barraclough a écrit :
On Feb 9, 2012, at 7:18 PM, Allen Wirfs-Brock wrote:
I would expect Gavin's approach to ultimately be even worse than mine
from a semantic analysis perspective. It expose (via
Object.getOwnPropertyDescriptor) functions that have the ability to
Le 10/02/2012 10:07, Gavin Barraclough a écrit :
On Feb 10, 2012, at 12:43 AM, David Bruant wrote:
Maybe I'm missing something, but what you're proposing is *exactly* a
frame-based check.
Hi David,
No, the proposed check does not correlate exactly to a frame-based
check. For example
Le 04/02/2012 01:14, John J Barton a écrit :
On Fri, Feb 3, 2012 at 3:14 PM, David Bruant bruan...@gmail.com wrote:
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:
I've been looking at Caja's code recently [1] and noticed
Le 04/02/2012 04:42, Mark S. Miller a écrit :
Considering the 2-argument eval example from above, you could define a
'document' property is the second argument and this document
(what the
eval code gets when it asks for the document variable) could be an
emulation of an
Le 04/02/2012 18:14, Mark S. Miller a écrit :
c) The ES6 module loader should make all these with-games unnecessary
anyhow, since it gives us a principled approach for controlling the
top level scope of untrusted code. Long term, this is the real answer.
Ok, good to know.
Can you show how
Le 03/02/2012 17:54, John J Barton a écrit :
On Fri, Feb 3, 2012 at 8:12 AM, Mark S. Miller erig...@google.com wrote:
On Fri, Feb 3, 2012 at 7:36 AM, John J Barton johnjbar...@johnjbarton.com
wrote:
[...]
I'm not saying we can't do better, I am claiming that the impact of
adding security
701 - 800 of 1196 matches
Mail list logo
