Le 15/12/2012 19:38, Allen Wirfs-Brock a écrit :
On Dec 15, 2012, at 9:21 AM, David Bruant wrote:
Hi,
On public-script-coord, Boris Zbarsky showed an example [1] where a global
variable is var-defined and then observed to be absent from the global object
it was attached to (because
Le 15/12/2012 19:11, Brendan Eich a écrit :
David Bruant wrote:
If I create a non-configurable property with a getter that I define
(such
as `() = 3`), I know that accessing the property will always produce
a known value.Relaxing this restriction means that proxies could
produce whatever
Le 15/12/2012 22:20, Brendan Eich a écrit :
David Bruant wrote:
Le 15/12/2012 19:11, Brendan Eich a écrit :
Frozen accessors would be best if we can get away with the
incompatibility.
I've given more thought. Frozen accessors can't be a solution. Only
deeply frozen would be.
Oh sure
...@mozilla.com
mailto:bren...@mozilla.com wrote:
David Bruant wrote:
Le 15/12/2012 19:11, Brendan Eich a écrit :
David Bruant wrote:
If I create a non-configurable property with a
getter that I define
Le 15/12/2012 16:14, David Bruant a écrit :
Le 15/12/2012 15:49, Sam Tobin-Hochstadt a écrit :
If I create a non-configurable property with a getter that I define
(such
as `() = 3`), I know that accessing the property will always produce
a known value.Relaxing this restriction means
Le 14/12/2012 08:25, Brendan Eich a écrit :
Mark S. Miller wrote:
On Thu, Dec 13, 2012 at 7:05 PM, Brendan
Eichbren...@secure.meer.net wrote:
Boris Zbarsky pointed out on public-script-coord that
window.location and
window.document must be non-configurable _ab initio_, but perhaps
this is
Le 14/12/2012 11:01, Andreas Rossberg a écrit :
On 13 December 2012 19:21, Mark S. Miller erig...@google.com wrote:
On Thu, Dec 13, 2012 at 1:12 AM, David Bruant bruan...@gmail.com wrote:
As you say, to remain viable, it
must be done quickly. From previous experience, I suggest that there's
Le 14/12/2012 19:04, Mark S. Miller a écrit :
On Fri, Dec 14, 2012 at 9:12 AM, Mark Miller erig...@gmail.com wrote:
On Fri, Dec 14, 2012 at 8:36 AM, Andreas Rossberg rossb...@google.com
wrote:
On 14 December 2012 16:54, Mark Miller erig...@gmail.com wrote:
Regarding what Andreas said and what
Le 13/12/2012 00:51, Mark S. Miller a écrit :
On Wed, Dec 12, 2012 at 11:19 AM, David Bruant bruan...@gmail.com wrote:
[...]
* change the behavior of WindowProxy instances when it comes to doing things
that would commit them to eternal invariants to throw instead of forwarding.
This solution
Le 13/12/2012 20:47, Jason Orendorff a écrit :
On Wed, Dec 12, 2012 at 3:44 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 12/12/2012 22:30, Kevin Reid a écrit :
The JS runtime won't know that the proxy has anything to do with
the actual Window instance
Hi,
A good question by Anne van Kesteren [1] followed by good remarks by
Boris Zbarsky [2][3] made me try a little something [4][5].
The WindowProxy object returned as the 'contentWindow' property of
iframes never changes; whatever you do when changing the @src, always
the same object is
Le 12/12/2012 20:29, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 11:19 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
A good question by Anne van Kesteren [1] followed by good remarks
by Boris Zbarsky [2][3] made me try a little something [4][5
/window.js#L35
On Wed, Dec 12, 2012 at 2:19 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Hi,
A good question by Anne van Kesteren [1] followed by good remarks
by Boris Zbarsky [2][3] made me try a little something [4][5].
The WindowProxy object returned
be an exception to the emulate DOM proxy use case?
David
On Wednesday, December 12, 2012, David Bruant wrote:
Le 12/12/2012 20:29, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 11:19 AM, David Bruant
bruan...@gmail.com javascript:_e({}, 'cvml',
'bruan...@gmail.com'); wrote
Le 12/12/2012 20:49, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 11:39 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 12/12/2012 20:29, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 11:19 AM, David Bruant
bruan...@gmail.com mailto:bruan...@gmail.com wrote
Le 12/12/2012 21:09, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 12:03 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 12/12/2012 20:49, Kevin Reid a écrit :
I haven't made it public yet, but it's just the obvious
implementation of an (old-style
Le 12/12/2012 21:42, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 12:35 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
I was a bit too strong in my statement, sorry. Let me rephrase:
the internal [[Target]] can't be changed, but a proxy can emulate
changing
Le 12/12/2012 22:30, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 1:23 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 12/12/2012 21:42, Kevin Reid a écrit :
Exactly. So a user-defined switching proxy needs only to:
1. refuse to commit to any invariant
Le 11/12/2012 21:46, Brandon Benvie a écrit :
http://github.com/benvie/continuum - project
http://benvie.github.com/continuum - debugger
npm module 'continuum'
Continuum is a virtual machine for executing ES6 code (the spec is
rapidly iterating so many things need updating). It's written in
Hi,
This post is not intentioned to be a perfect and final guide, but rather
a conversation starter.
It's mostly triggered by what Andrea described as a potential attack
(assigning Object.prototype.get).
# Description of the JS runtime
To a first approximation (ignoring things like
Le 04/12/2012 20:25, Jason Orendorff a écrit :
On Sat, Dec 1, 2012 at 2:09 AM, Mathias Bynens math...@qiwi.be
mailto:math...@qiwi.be wrote:
On 30 Nov 2012, at 22:50, Norbert Lindenberg
ecmascr...@norbertlindenberg.com
mailto:ecmascr...@norbertlindenberg.com wrote:
There's
Le 03/12/2012 00:06, David Bruant a écrit :
The call to action performs
the original operation on target and remembers the result. After the
trap returns, the proxy returns the remembered result of action.
target = {a:1};
var p = new Proxy(target, {
get: function(target, name
that custom property descriptor attributes are
lost with action-proxies. I'm not sure yet what is a good way to recover
them.
David
On Mon, Dec 3, 2012 at 3:33 AM, David Bruant bruan...@gmail.com wrote:
Le 03/12/2012 00:06, David Bruant a écrit :
The call to action performs
the original operation
Le 02/12/2012 17:27, Tom Van Cutsem a écrit :
2012/11/28 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
I don't understand why a unique token per trap invocation would
be necessary.
I still don't understand this point.
I've gone spelunking. I've found
Le 02/12/2012 17:43, David Bruant a écrit :
Maybe I'm too influenced by the JVM, but my understanding is that
wrapping every call to a trap with a try-catch block won't be free.
The more interesting question is whether it would be significantly
cheaper than 'returning a value+invariant checks
Le 02/12/2012 18:34, Mark S. Miller a écrit :
On Sun, Dec 2, 2012 at 8:40 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
- after-style wrapping allows you to get notified of an operation
after-the-fact. Depending on the API, the after-wrapper may or may not get
to see the outcome of the
Le 02/12/2012 20:40, Tom Van Cutsem a écrit :
2012/12/2 Mark S. Miller erig...@google.com mailto:erig...@google.com
I think we can rescue around wrapping. I'll call this approach opaque
around wrapping. The idea is that the proxy passes into the handler
trap a proxy-generated
Le 29/11/2012 06:20, Brandon Benvie a écrit :
The answer though in that case is easy enough though, make sure the
prototype descriptor is created with Object.create(null). This
wouldn't solve compatibility issues with in-the-wild code but it
solves the issue for most people who care enough to
Le 29/11/2012 09:41, Jussi Kalliokoski a écrit :
It's a bit unclear to me how arrow functions react to semicolons, for
example:
var a = (c) = {
var b = 2;
b * c;
}
a(4);
To me, it seems like this should return undefined. After all, the last
statement in the function is empty. To
Le 29/11/2012 16:47, Nathan Wall a écrit :
In addition, it'd be nice if there was an easier way to create an
object with no [[Prototype]]... some sort of addition to object
literal notation?
I think ES6 will have such a notation with the __proto__ de facto
standardization:
var o = {
Le 29/11/2012 17:02, Allen Wirfs-Brock a écrit :
On Nov 29, 2012, at 7:47 AM, Nathan Wall wrote:
Seems pretty excessive. It's probably too late to make defineProperty
only look at own properties, but how about making it ignore
properties inherited from Object.prototype?
Fairly complex to
Hi Marius,
I won't say the idea is bad, but what would be the benefit of this new
type of function?
From experience on this list, if a new idea cannot prove to make a
major difference with what currently exists, it is not considered to be
added to the ES6 spec.
The major difference can be
Le 28/11/2012 14:47, Marius Gundersen a écrit :
On Wed, Nov 28, 2012 at 1:21 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Hi Marius,
I won't say the idea is bad, but what would be the benefit of this
new type of function?
From experience on this list
Le 28/11/2012 18:19, Claus Reinke a écrit :
With many new functional programming possibilities (like map,
reduce, filter, lambdas) there are many scenarios where the
implementer should use pure (or as I renamed it in another reply,
side-effect-free) functions.
Why should? What is the problem
Le 28/11/2012 21:35, Oliver Hunt a écrit :
On Nov 28, 2012, at 12:25 PM, Waldemar Horwat walde...@google.com
mailto:walde...@google.com wrote:
On Wed, Nov 28, 2012 at 5:39 AM, Marius Gundersen
gunder...@gmail.com mailto:gunder...@gmail.com wrote:
On Wed, Nov 28, 2012 at 1:20 PM,
Le 26/11/2012 21:39, David Bruant a écrit :
Le 26/11/2012 20:59, Tom Van Cutsem a écrit :
2012/11/26 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
We could define a symbolic value (like StopIteration for
iterators) that would mean forward to target. By essence of
what
Le 27/11/2012 02:27, Brendan Eich a écrit :
David Bruant wrote:
Le 26/11/2012 22:11, Brendan Eich a écrit :
Herby Vojčík wrote:
Hi,
shouldn't StopIteration, ForwardToTarget from Notification
proxies thread and similar ones be rather well-known unique
symbols (like @iterator), now that we
Hi,
var o = {};
WeakMap.call(o);
WeakSet.call(o);
Map.call(o);
Set.call(o);
Currently, this works and makes o a weakmap, a weakset, a map and a set...
I understand collections were spec'ed to enable subclassing, but I don't
see the value of being able to subclass this way
Le 27/11/2012 14:02, David Bruant a écrit :
Hi,
var o = {};
WeakMap.call(o);
WeakSet.call(o);
Map.call(o);
Set.call(o);
Currently, this works and makes o a weakmap, a weakset, a map and a
set...
I understand collections were spec'ed to enable subclassing, but I
don't see
Hi,
Just forwarding to an announcement elsewhere made:
http://mail.openjdk.java.net/pipermail/announce/2012-November/000139.html
The code hasn't been released yet from what I understand, but that's
interesting to keep an eye on that I think.
David
Le 25/11/2012 15:32, Axel Rauschmayer a écrit :
If indeed both kinds of proxy are useful and direct proxies are more
powerful, then why not only have a foundational direct proxy API and
implement a tool type NotificationProxy that is based on that API.
An interesting question I still haven't
Le 25/11/2012 12:44, Tom Van Cutsem a écrit :
(...)
I agree that the big benefit of notification proxies is that they get
rid of all the complex validation logic.
However, some reservations:
(...)
- I think we do lose some expressiveness in the case of pure virtual
object abstractions that
Le 26/11/2012 19:37, Allen Wirfs-Brock a écrit :
On Nov 26, 2012, at 10:00 AM, Tom Van Cutsem wrote:
2012/11/24 Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com
I see that [2] call for filtering __proto__ access in Get/Put
handlers. I think that dealing with
Le 26/11/2012 19:58, Allen Wirfs-Brock a écrit :
On Nov 26, 2012, at 12:36 AM, David Bruant wrote:
Le 25/11/2012 15:32, Axel Rauschmayer a écrit :
If indeed both kinds of proxy are useful and direct proxies are more
powerful, then why not only have a foundational direct proxy API
Le 26/11/2012 20:59, Tom Van Cutsem a écrit :
2012/11/26 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
We could define a symbolic value (like StopIteration for
iterators) that would mean forward to target. By essence of what
forwarding to the target means, there would
Le 26/11/2012 22:11, Brendan Eich a écrit :
Herby Vojčík wrote:
Hi,
shouldn't StopIteration, ForwardToTarget from Notification proxies
thread and similar ones be rather well-known unique symbols (like
@iterator), now that we have them, instead of well-known globals? \
Why?
Let's separate
Le 25/11/2012 01:32, Brendan Eich a écrit :
David Bruant wrote:
Here is an idea to uniformize the enumeration story while removing
enumeration inconsistency footgun. I'll describe it in proxy trap
terms. A unique trap (or internal operation)
keyEnumerate: () - iterator for {propertyKey
Hi,
I haven't been following very closely some of the most recent
discussions, so I appologize if my comments have been addressed already
Le 23/11/2012 18:48, Allen Wirfs-Brock a écrit :
Changes include:
. Reorganized Chapter 8 into separate language type and specification
type sub
Le 24/11/2012 15:23, Herby Vojčík a écrit :
David Bruant wrote:
Hi,
I haven't been following very closely some of the most recent
discussions, so I appologize if my comments have been addressed already
Le 23/11/2012 18:48, Allen Wirfs-Brock a écrit :
Changes include:
• MOP changes: Added
Le 24/11/2012 14:58, Axel Rauschmayer a écrit :
• MOP changes: Added [[GetInheritance]]/[[SetInheritance]] as
internal methods for accessing [[Prototype]] internal prototype chain.
Why not [[GetPrototype]] and [[SetPrototype]]? We have a absurd
number of excellent resources (including but not
Le 24/11/2012 18:10, Allen Wirfs-Brock a écrit :
* [[Enumerate]], [[Keys]] and [[OwnPropertyKeys]] are very close
operations
* So are [[PreventExtensions]]/[[Freeze]]/[[Seal]] on one side and
[[IsExtensible]]/[[IsFrozen]]/[[IsSealed]]
I'm afraid that making them distinct operations increases
Le 22/11/2012 21:44, Allen Wirfs-Brock a écrit :
See https://bugs.ecmascript.org/show_bug.cgi?id=922
What do people think? Should a repeat count of 0 be accepted and
produce an empty string?
I would expect so.
David
___
es-discuss mailing list
Hi,
From the Bugzilla [1], Allen:
(...) in rev 12 [property descriptors] have been enhanced to include a
reference to the object (if any) they were produced from. This permits
an descriptor object to pass through the traps behind
Object.getOwnpropertyDesceriptor and Object.defineOwnProperty
Le 21/11/2012 01:06, Allen Wirfs-Brock a écrit :
b) that all the elements of the result are Strings
And presumably Symbols. We have to also accommodate Symbols, at
least for getOwnPropetyNames. Regardless, why is this
important? More below...
Same argument as above.
I
Le 21/11/2012 17:37, Allen Wirfs-Brock a écrit :
On Nov 21, 2012, at 1:55 AM, David Bruant wrote:
Le 21/11/2012 01:06, Allen Wirfs-Brock a écrit :
b) that all the elements of the result are Strings
And presumably Symbols. We have to also accommodate Symbols,
at least
Le 21/11/2012 21:13, Tom Van Cutsem a écrit :
2012/11/21 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Since the use of Object.getOwnPropertyNames may not be widespread,
maybe that making non-enumerable unique symbol properties could do
the trick (as it has with new
Le 14/11/2012 10:34, Andreas Rossberg a écrit :
On 14 November 2012 09:30, Tom Van Cutsem tomvc...@gmail.com wrote:
2012/11/13 David Bruant bruan...@gmail.com
For the particular case you've written, when going for hasOwnProperty.call
or the in operator, the JS engine knows it needs to output
Le 19/11/2012 12:37, Brendan Eich a écrit :
David Bruant wrote:
So my position is let's not bake performance bottlenecks in the
language (which we tend to do naturally anyway) and for things that
can be optimized, let's say that the implementations will pay the
cost of the static/runtime
Le 14/11/2012 07:35, Brendan Eich a écrit :
Also Tom's point about precision counts, independent of allocations. A
hasOwn test in the MOP should not call the same thing that
Object.getOwnPropertyDescriptor calls, if we can help it
I don't think it's possible. This thread started with the
Le 12/11/2012 19:17, Allen Wirfs-Brock a écrit :
On Nov 12, 2012, at 2:21 AM, Brandon Benvie wrote:
Shouldn't it be the reverse, based on the removal of
getPropertyDescriptor/Names? The proxy controls what i's [[Prototype]] is which
indirectly directs how non-own lookups proceed. The
(sorry for the late answer, I was traveling and at an event since Thursday)
Le 12/11/2012 02:46, Leo Meyerovich a écrit :
I wasn't aware of this and then read through about a dozen WebAPIs [2] between
yesterday and today and... discovered it's the case. In my opinion, one of the
most absurd
Le 09/11/2012 18:01, John J Barton a écrit :
On Fri, Nov 9, 2012 at 4:33 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
# the Q API
## A Q Deferred is a {promise, reject, resolve} object. Only the
deferred holder can resolve the promise (and not the promise
Le 10/11/2012 03:14, Brendan Eich a écrit :
David Bruant wrote:
Personally, to synchronize different async operations, I've never
read code more elegant than what Q.all offers.
What about task.js's join?
https://github.com/mozilla/task.js/blob/master/examples/read.html#L41
I feel it's pretty
, Nov 9, 2012 at 4:33 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
[...]
## Q.all
My favorite feature is the Q.all function. Q.all accepts an array
of promises and returns a promise which will be fulfilled when all
promises are. The resolution values
Le 11/11/2012 14:44, Kevin Smith a écrit :
Is the following a counter-example?
On Fri, Nov 9, 2012 at 8:33 AM, Mark S. Miller erig...@google.com
mailto:erig...@google.com wrote:
Hi David, thanks for your thoughtful post. I've always used
the two-arg form of
Le 13/11/2012 19:28, Allen Wirfs-Brock a écrit :
On Nov 13, 2012, at 1:44 AM, David Bruant wrote:
I'm fine if we're discussing removing some other inconsistencies, but I'd be
more interested in seeing a principled way to decide which inconsistency we're
getting rid of and which we still allow
Le 13/11/2012 21:25, Tom Van Cutsem a écrit :
2012/11/13 Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com
I think there is agreement that [[HasOwnProperty]] is just an
optimization of ToBoolean([[GetOwnPropertuy]]). Its only purpose
is to avoid unnecessary
Le 09/11/2012 00:05, Jeff Walden a écrit :
On 10/26/2012 02:30 PM, David Bruant wrote: Le 26/10/2012 22:56, Asen Bozhilov
a écrit :
var obj = Object.defineProperty({}, '__proto__', {
get : function () {return '__proto__ getter'},
set : function (){return '__proto__ setter
Le 07/11/2012 18:17, Axel Rauschmayer a écrit :
In theory, one can use prototype properties to provide default values
for instance properties. In practice, that is not often useful,
because the constructor normally creates all instance properties right
away, assigning default values where
Hi,
In a post to public-script-coord yesterday, Alex Russel wrote the
following [1]:
[Web]IDL *is handy. *More to the point, it's the language of the specs
we have now, and the default mode for writing new ones is copy/paste
some IDL from another spec that looks close to what I need and then
Le 06/11/2012 20:07, Axel Rauschmayer a écrit :
That’s at a weird intersection between HTML5 and ECMAScript, (...)
I think it's more historical than anything. The event loop,
setTimeout/Interval (and promises) belong to the language (ECMAScript),
not to a library (HTML5) in my opinion.
Le 06/11/2012 20:35, Rick Waldron a écrit :
Based on a read through of
https://github.com/promises-aplus/promises-spec, these things
initially come to mind, please regard as a loose collection of varying
thoughts that may or may not be completely relevant:
1. The definition of a promise is
Le 05/11/2012 22:11, Andrea Giammarchi a écrit :
I see security problems all over ... you own your function, you can
make it pure or serializable ... you don't know your function, I
believe there's no way you want that unknown function to be executed
in your own sandbox opening doors for any
Le 02/11/2012 23:08, Allen Wirfs-Brock a écrit :
(...)
Here is the new structure that I have in mind, with reference to existing ES5
(section numbers:)
Introductory Material
The ECMAScript Computational Engine
The ECMAScript Programming Language
The ECMAScript Standard Library (15)
Le 02/11/2012 09:33, Tom Van Cutsem a écrit :
2012/11/1 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Currently, TrapGetOwnProperty returns an object, but when there is an
actual trap, it goes through:
* NormalizeAndCompletePropertyDescriptor(Object) - Object (step 6
Le 02/11/2012 12:20, Tom Van Cutsem a écrit :
Hi Allen,
2012/11/1 Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com
The above isn't how this will be expressed in the final spec.
Instead we will have
3) Let desc be the result of calling the
It does not apply to WeakMaps, but otherwise, I agree it's a nice method
to have on Map and Set.
David
Le 02/11/2012 18:26, Nicholas C. Zakas a écrit :
I had mentioned this in passing in a previous email, but wanted to
bring it up again.
As I've been playing more with maps and sets, I've
Le 02/11/2012 16:39, Allen Wirfs-Brock a écrit :
So, yes, in that case Object.getOwnPropertyDescriptor and
Object.defineProperty need to pass through object level descriptors
from/to the corresponding proxy traps which means they can't normalize
via a property descriptor record. So, it is
Le 01/11/2012 10:37, Tom Van Cutsem a écrit :
On the other hand, as so carefully explained by Allen, there currently
isn't really an issue with the mapping between property descriptors
and objects: at all the boundary points, we make sure to properly
convert descriptors into well-behaved
Hi,
I've recently filed a spec bug [1] and given more thoughts about it that
goes beyond the suggested restructuring so I'm bringing it up here. This
posts ends up with an unresolved issue, but I hope a solution can be found.
Let's talk about property descriptors. Currently, in the spec,
Le 31/10/2012 12:46, Andreas Rossberg a écrit :
On 31 October 2012 10:40, David Bruant bruan...@gmail.com wrote:
My bug was about making the use of objects [for property descriptors]
official in the spec internals... until I realized that ES6 has maps.
Can you motivate why maps would be more
Le 27/10/2012 00:59, Mark S. Miller a écrit :
On Fri, Oct 26, 2012 at 3:45 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 27/10/2012 00:23, Kevin Reid a écrit :
How about: there must be no /nonstandard non-configurable
properties/ of standard objects
Le 27/10/2012 03:04, Mark S. Miller a écrit :
On Fri, Oct 26, 2012 at 5:45 PM, Waldemar Horwat walde...@google.com
mailto:walde...@google.com wrote:
How about: there must be no /nonstandard non-configurable
properties/ of standard objects.
Wouldn't that just preclude
2012/10/26 Isaac Schlueter i...@izs.me
(...)
We've got some band-aids in place in the node http.js file to prevent
parser leaks. A more forcible free() method would have made it much
easier. The long-term solution is to rewrite the program (...)
So you're suggesting that a language-level
Le 26/10/2012 07:28, Patrick Mueller a écrit :
On Thu, Oct 25, 2012 at 4:16 PM, Isaac Schlueter i...@izs.me
mailto:i...@izs.me wrote:
It'd be really nice if JS had a way to explicitly delete an object.
Didn't proxies have some way of doing a become: and freezing
Le 26/10/2012 13:59, Patrick Mueller a écrit :
On Fri, Oct 26, 2012 at 2:03 AM, David Herman dher...@mozilla.com
mailto:dher...@mozilla.com wrote:
A feature you shouldn't use in production is a feature your
attackers will use in production. ;)
Not just your attackers. Worse. You,
Le 26/10/2012 22:56, Asen Bozhilov a écrit :
I would like to define custom getter and setter for `__proto__`
property:
var obj = Object.defineProperty({}, '__proto__', {
get : function () {return '__proto__ getter'},
set : function (){return '__proto__ setter'}
});
Le 26/10/2012 21:29, Mark S. Miller a écrit :
(...)
#3 as is is unacceptable, because the spec would be inadequate to
reason about the security of a SES-for-ES6.
I don't understand why it's the case. Both for built-ins and new syntax,
if there is no caller nor arguments property at all, I
Le 26/10/2012 23:57, Mark S. Miller a écrit :
#3 as is does not require implementations to not provide magic
insecurable caller and arguments properties, just as ES5 by itself
does not require implementations to not provide such properties on
built-ins. Indeed, before many side conversations,
Le 27/10/2012 00:23, Kevin Reid a écrit :
How about: there must be no /nonstandard non-configurable
properties/ of standard objects.
This directly implies SES can do its job of deleting everything not
whitelisted, and does not rely on the spec blacklisting undesirable
behaviors.
Interesting.
Le 25/10/2012 12:42, Axel Rauschmayer a écrit :
I'm not sure I understand the benefit of making it easy to develop
APIs where foo.bar() is not roughly equivalent to (x =
foo.bar).apply(foo). Am I misunderstanding something?
Right. Keeping that invariant is important.
I’d like to avoid (the
Hi Domenic,
I'm not sure it's that important to talk about weaksets *and* weakmap. One
or the other is enough assuming you've talked about maps and sets
beforehand.
In several slides, I see that you're using the following form:
var empireJS = {
preParty(){ // -- this
2012/10/20 Axel Rauschmayer a...@rauschma.de
https://gist.github.com/3918227
I’m wondering what this approach does better.
Originally, it really was to give some (built-in) syntactic sugar to
(Weak)Map. No plan to make objects better. At most sharing a simpler object
model than the ES5 one.
2012/10/20 Axel Rauschmayer a...@rauschma.de
1. Accidentally accessing inherited properties: fixed
2. Can’t safely invoke methods, because those might be overridden: still
a problem (right?)
3. __proto__: fixed
[...]
About your second point, it assumes that we want all objects to have
Hi,
This is just a short note.
In the previous design, some internal proxy operations threw when there was
a missing fundamental trap. We also considered at some point making missing
traps of Handler (previously VirtualHandler) [1] throw as well (I suggested
to make
2012/10/15 Kevin Smith khs4...@gmail.com
Hi all,
With modules, we're going to see code broken up into more and smaller
files, which directly opposes the desire to minimize the number of HTTP
round-trips.
Arguably, by the time we can use ES6 modules, browsers will support
HTTP/2.0 with which
2012/10/15 Brendan Eich bren...@mozilla.org
* get/set accessor may have effects on 'set' (see the DOM) but only on the
receiver object (and unobservably,
I think that unobservably will be very hard (if not impossible in most
cases) to achieve with proxies.
Unobservable except to the receiver
2012/10/12 Geoffrey Sneddon gsned...@opera.com
On 12/10/12 14:50, David Bruant wrote:
I was looking at Bugzilla and came across two bugs [1] [2] related to
Mootools-based (only Mootools 1.2-) websites being broken by the inclusion
of String.prototype.contains in SpiderMonkey.
I don't think
2012/10/12 Alex Russell slightly...@google.com
I feel like there's as PSA we should write over on webplatform.org for
library authors about how to not be future hostile.
Some context for those who wouldn't have followed.
The W3C, major (western?) browser makers, Nokia, Facebook, HP, Adobe
2012/10/13 Alex Russell slightly...@google.com
On Sat, Oct 13, 2012 at 12:34 PM, David Bruant bruan...@gmail.com wrote:
Since it's in such an early stage and it's not really well-known and
well-established, is webplatform.org the right place to do a PSA as you
suggest?
Do you have
501 - 600 of 1196 matches
Mail list logo
