Hi,
I've tried to search for getPropertyDescriptor in
https://mail.mozilla.org/pipermail/es-discuss/ and I've been sent to a
page displaying the following 2 lines :
--
htfuzzy: Unable to open word database /var/lib/htdig/db.words.db
htfuzzy: Unable to open word database
Hi,
I am wondering if getPropertyDescriptor and getPropertyNames fundamental
traps shouldn't rather be derived traps since they could have a pretty
straightforward default implementation.
One implementation of getPropertyNames could be :
--
Object.getPropertyNames =
the discussions we
already have seen on the Proxy hub, is that it’s a great feature, but
one that still needs some work before implementation ;-)
Regards,
François
*From:* David Bruant mailto:bru...@enseirb-matmeca.fr
*Sent:* Sunday, January 23, 2011 4:24 PM
*To:* es-discuss mailto:es
. But is there a reason ?
This is my question.
Regards,
François
*From:* David Bruant mailto:bru...@enseirb-matmeca.fr
*Sent:* Sunday, January 23, 2011 7:29 PM
*To:* François REMY mailto:fremycompany_...@yahoo.fr
*Cc:* es-discuss mailto:es-discuss@mozilla.org ; Mark S. Miller
mailto:erig...@google.com
Hi,
In getOwnPropertyDescriptor and getPropertyDescriptor traps of the no-op
forwarding proxy example, the desc.configurable = true instruction
fails if desc is undefined (which happens when the property is undefined).
A if(typeof(desc) === 'object') beforehand saves the situation.
Just for the
needs some work
before implementation ;-)
Regards,
François
*From:* David Bruant mailto:bru...@enseirb-matmeca.fr
*Sent:* Sunday, January 23, 2011 4:24 PM
*To:* es-discuss mailto:es-discuss@mozilla.org
*Cc:* Mark S
Le 26/01/2011 19:17, Brendan Eich a écrit :
On Jan 26, 2011, at 9:54 AM, David Bruant wrote:
Le 26/01/2011 17:45, Tom Van Cutsem a écrit :
Ok, so Mark and I briefly discussed the implications of making
getPropertyDescriptor and getPropertyNames derived.
Here's one issue: if you try
On Jan 26, 2011, at 11:02 AM, David Bruant wrote:
On the question of proxy parameters for all traps (well,
receiver for get and set): fewer args are better, and closure
capture of proxy by handler avoids leaking the proxy to handler
friends, if that matters. Likewise you can't
Hi,
In ES5 11.4.3, which defines the semantics of typeof, is written that
native objects (as proxies will be since they'll be within the scope of
the spec) which do not implement a [[call]] trap should return object
with typeof.
Currently, the proxy spec doesn't separate the case when the call
Hi,
I have decided to work on trying to (re-)implement native arrays with
proxies. All the code is here: https://github.com/DavidBruant/ProxyArray
and I'd like to provide some feedback.
* The approach
The basic idea was to:
- use a forwarding proxy
- change the defineProperty trap into an
Le 30/01/2011 16:58, Tom Van Cutsem a écrit :
2011/1/28 David Bruant bru...@enseirb-matmeca.fr
mailto:bru...@enseirb-matmeca.fr
Based on that definition, we could have a stronger definition of
derived traps:
Derived trap are defined as ES code using fundamental traps
[adding Cameron McCormack, Web IDL editor, to the discussion]
Le 14/02/2011 22:29, Adam Barth a écrit :
On Mon, Feb 14, 2011 at 12:49 PM, Brendan Eich bren...@mozilla.org wrote:
On Feb 14, 2011, at 12:26 PM, Adam Barth wrote:
On Mon, Feb 14, 2011 at 11:56 AM, Brendan Eich
Le 23/02/2011 23:26, David Herman a écrit :
I've been working on a prototype implementation of the binary data spec in
pure JS (implemented via typed arrays) and I've been bitten by the lack of a
standard mechanism for subclassing Function.
I'm using proxies for the implementation, and
Le 23/02/2011 23:54, David Herman a écrit :
With your optional argument, I see a second solution that could be
consistent. The prototype chain could contain the provided prototype
then Function.prototype (obj -- proto -- Function.prototype --
null as opposed to your proposition which is: obj
Ok... hmm... well...
I misread your initial post. You wanted to enforce the condition on the
argument proto object, not the object returned by Proxy.createFunction.
My apologies, here's my fixed response:
Le 24/02/2011 11:42, David Bruant a écrit :
Le 24/02/2011 02:32, David Herman a écrit
Hi,
I have once seen a presentation from Douglas Crockford where he was
saying that new ECMAScript features would be developed on top of ES
strict mode (sorry for not having the exact quote, I hope I'm not
misinterpreting). I have re-read that Harmony is a super-set of ES5
strict
Hi,
After reading this page
(http://wiki.ecmascript.org/doku.php?id=strawman:handler_access_to_proxy),
I thought of another idea.
Maybe that instead of adding an argument to all handler methods, we
could add a property to the handler.
Each time a proxy p method m is trapped (with handler h):
-
that this option doesn't solve the first motivating
use case (shared handler) since some method are disadvantaged regarding,
for instance, being able to store per-proxy state.
Cheers,
David
Cheers,
Tom
Cheers,
David
Cheers,
Tom
2011/2/28 David Bruant bru...@enseirb
[Adding WhatWG and public-script-coord (WebIDL) to the discussion.
Discussion is ongoing :
- Start of thread :
https://mail.mozilla.org/pipermail/es-discuss/2011-March/012915.html
- Strawman by Dave Herman:
http://wiki.ecmascript.org/doku.php?id=strawman:multiple_globals )]
---
Le 11/03/2011 00:48, Charles Kendrick a écrit :
I believe it is very very important that the ECMAScript standard
specify that when a new Object
is created, for..in iteration traverses properties in the order they
are added, regardless of whether the properties are numeric or not.
(...)
==
Le 11/03/2011 17:13, John Lenz a écrit :
This whole discussion makes reminds me how much JavaScript needs
proper collections. People use Object but they don't really want
Object (where prototype properties leak into data, where they String
is the only key type, where the strings 1.0 and 1 can
Le 11/03/2011 23:07, Charles Kendrick a écrit :
On 3/11/2011 1:33 PM, David Bruant wrote:
Le 11/03/2011 21:49, Charles Kendrick a écrit :
Yes Allen, hence the urgency. If IE9 final ships that way, the goose
is cooked:
Let's face it right now: IE9 will ship that way. They're on RC phase
Le 12/03/2011 11:29, Tom Schuster a écrit :
Hi,
the current definition of [[Construct]] doesn't allow to create
non-constructable objects, but instead just invokes the call handler.
On easy hackaround would be to check if the constructhandler has a
[[Construct]] internal method. Then you
Le 12/03/2011 09:06, Brendan Eich a écrit :
On Mar 11, 2011, at 12:49 PM, Charles Kendrick wrote:
Yes Allen, hence the urgency. If IE9 final ships that way, the
goose is cooked:
I hear tell of something happening next Monday. Goose, well-done,
stuffed, I think.
1. we will have a new de
Le 12/03/2011 19:41, Brendan Eich a écrit :
On Mar 12, 2011, at 9:54 AM, David Bruant wrote:
The little issue I see in returning 1) index properties in ascending
order 2) all other properties in addition order is that there is a bit
of information lost in the process: overall property addition
Le 12/03/2011 20:58, David Bruant a écrit :
Le 12/03/2011 19:41, Brendan Eich a écrit :
On Mar 12, 2011, at 9:54 AM, David Bruant wrote:
The little issue I see in returning 1) index properties in ascending
order 2) all other properties in addition order is that there is a bit
of information
Le 12/03/2011 21:24, Allen Wirfs-Brock a écrit :
On Mar 12, 2011, at 11:58 AM, David Bruant wrote:
Le 12/03/2011 19:41, Brendan Eich a écrit :
On Mar 12, 2011, at 9:54 AM, David Bruant wrote:
The little issue I see in returning 1) index properties in ascending
order 2) all other properties
Hi,
I think it would be worth for spec readability to give a name to the
for-in property enumeration internal method and list it as such in ES5
8.6.2 Table 8 regardless the fact that it is implementation-dependent.
From the spec edition point of view, it would require a bit of
re-writing for the
Le 13/03/2011 10:57, Claus Reinke a écrit :
The little issue I see in returning 1) index properties in
ascending
order 2) all other properties in addition order is that there is a
bit
of information lost in the process: overall property addition order
(index properties included).
..
Music
.
/be
On Mar 13, 2011, at 12:08 PM, David Bruant wrote:
Hi,
I would like to discuss the terminology of the proposal and the two
states of a proxy: trapping or fixed.
In order to discuss, here is a little example:
-
var o = {};
var p = Proxy.create( forwardingHandler
. It also maintains all the other behaviors of
the original proxy [[Call]] and [[Construct]] hooks, i.e. new f() can
return 5. I am not sure whether this difference warrants talking
about fixed proxies, but I wanted to point it out.
Andreas
On Mar 13, 2011, at 10:08 AM, David Bruant wrote
Le 14/03/2011 17:02, John Tamplin a écrit :
On Mon, Mar 14, 2011 at 10:21 AM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Web developers find and exploit many de-facto standards.
Enumeration order being insertion order for non-arrays at least,
if not for
Le 12/03/2011 23:45, David Bruant a écrit :
Hi,
I think it would be worth for spec readability to give a name to the
for-in property enumeration internal method and list it as such in ES5
8.6.2 Table 8 regardless the fact that it is implementation-dependent.
From the spec edition point
Hi,
I've been thinking about Function proxy use cases lately. Things that
the spec do and that could be convenient to emulate as well or just
things that could be useful.
* [[Construct]]-less functions.
All Array.prototype methods are like that as well as all global object
methods (parseInt...)
Dave
On Mar 12, 2011, at 1:15 PM, David Bruant wrote:
Hi,
The thread entitled iteration order for Object made me realize
that there is no defineProperties trap.
Let's imagine I'd like to implement an object which would keep track
of order in which own properties have been added/deleted
Le 15/03/2011 00:52, David Bruant a écrit :
Hi,
I've been thinking about Function proxy use cases lately. Things that
the spec do and that could be convenient to emulate as well or just
things that could be useful.
* [[Construct]]-less functions.
All Array.prototype methods are like
Le 15/03/2011 18:07, Allen Wirfs-Brock a écrit :
I think there is something deeper lurking behind this issue. Proxies can be
used to define objects whose property semantics can be quite different from
those of native objects. In some situations the built-in Object. reflection
functions are
Hi,
On the proxy proposal is an open issue. It starts with How to deal with
inconsistent data returned by handler traps? (actually, the issue also
applies to inputs since I can provide garbage as Object.defineProperty
arguments). First of all, I think that there might be a false assumption
in the
make a note of your Proxy.isProxy suggestion, should this method
ever be spec'ed.
2011/3/13 David Bruant bru...@enseirb-matmeca.fr
mailto:bru...@enseirb-matmeca.fr
That's a very interesting point.
But there is indeed a subtle difference between call/construct
traps and the rest
David Bruant bru...@enseirb-matmeca.fr
mailto:bru...@enseirb-matmeca.fr
Le 15/03/2011 00:52, David Bruant a écrit :
Hi,
I've been thinking about Function proxy use cases lately. Things
that the spec do and that could be convenient to emulate as well
or just things
objected on
the grounds that this approach could be prohibitively expensive for
some checks, such as filtering out duplicates.
Cheers,
Tom
2011/3/16 David Bruant bru...@enseirb-matmeca.fr
mailto:bru...@enseirb-matmeca.fr
Hi,
On the proxy proposal is an open issue. It starts
Le 18/03/2011 18:02, John-David Dalton a écrit :
Date.create, Function.create and the like clutters the API. I would be
for a more generic Object.setPrototypeOf() addition.
http://es5.github.com/#x15.2.3.2
The problem is that it would break an invariant of the ECMAScript
language which is that
Le 18/03/2011 18:00, Oliver Hunt a écrit :
I kind of dislike the proliferation of .create methods. It's seems
inelegant. What if we had (use __proto__ for semantic description)
Object.subclass = function(constructor) {
use strict;
function cons() {
var result =
Le 18/03/2011 18:00, Oliver Hunt a écrit :
I kind of dislike the proliferation of .create methods. It's seems
inelegant. What if we had (use __proto__ for semantic description)
Object.subclass = function(constructor) {
use strict;
function cons() {
var result =
Le 19/03/2011 01:11, Brendan Eich a écrit :
On Mar 15, 2011, at 6:43 PM, David Bruant wrote:
Unfortunately, currently, on FF4, the property descriptor is
rewritten, but with my comments on the code, you can see what results
I would expect. But the potential of having my library-specific
the program event.) I'm not
sure whether this is worth trying to accomplish in time for ES.next,
though.
Does the fact that some event loop formalization work has already been
done by the WHATWG within Standard HTML change your opinion on the matter?
David
Dave
On Mar 18, 2011, at 5:51 AM, David
Le 19/03/2011 16:39, David Herman a écrit :
It seems to me there are a couple pieces to Mark's concurrency
proposal. One part is formalizing the event queue that already exists.
Is this already done in the current proposal? Because I haven't found
it.
Sorry, I guess I should say, we can't
Le 19/03/2011 17:58, Mark S. Miller a écrit :
On Sat, Mar 19, 2011 at 5:59 AM, David Bruant david.bru...@labri.fr
mailto:david.bru...@labri.fr wrote:
I fully agree that the current proposal and all related work
(yours included) offer very powerful mecanisms and solutions
Le 19/03/2011 21:05, Mark S. Miller a écrit :
On Sat, Mar 19, 2011 at 10:57 AM, David Bruant david.bru...@labri.fr
mailto:david.bru...@labri.fr wrote:
I think there would be a need to wrapped the passed callback in
order to achieve garbage collection.
I didn't understand
Le 20/03/2011 04:11, Brendan Eich a écrit :
On Mar 19, 2011, at 4:20 PM, Sam Tobin-Hochstadt wrote:
On Sat, Mar 19, 2011 at 6:50 PM, Brendan Eich bren...@mozilla.com wrote:
setTimeout does not introduce threads, shared memory among them, or even
non-determinism if we spec carefully (browsers
Le 20/03/2011 14:33, Jorge Chamorro a écrit :
On 20/03/2011, at 13:51, Jorge wrote:
On 20/03/2011, at 12:08, David Bruant wrote:
Le 20/03/2011 04:11, Brendan Eich a écrit :
On Mar 19, 2011, at 4:20 PM, Sam Tobin-Hochstadt wrote:
On Sat, Mar 19, 2011 at 6:50 PM, Brendan Eich bren
Le 20/03/2011 16:04, Jorge a écrit :
On 20/03/2011, at 15:18, David Bruant wrote:
Le 20/03/2011 14:33, Jorge Chamorro a écrit :
A timer that expires is an event, and I would expect events to be serviced
in the order they happen. As when I click twice, I'd expect the first
click
Le 20/03/2011 16:56, David Herman a écrit :
This is giving me a (terrible) idea to implement setTimeout.
We could have two vats. One asks the second to resolve some promise
after a certain amout of time. The second loops and resolve the promise
when the delay is passed (measured as a delta
Le 20/03/2011 17:25, Jorge a écrit :
On 20/03/2011, at 16:57, David Bruant wrote:
Le 20/03/2011 16:04, Jorge a écrit :
On 20/03/2011, at 15:18, David Bruant wrote:
Le 20/03/2011 14:33, Jorge Chamorro a écrit :
A timer that expires is an event, and I would expect events to be
serviced
Le 20/03/2011 17:14, Kyle Simpson a écrit :
I don't see why you can't verify your expectation.
If you think you can verify your expectation, please write ECMAScript
interoperable test cases that show how to test whether an ECMAScript
engine is conform to your scheduling policy or not. It will
Hi,
Proxies can be helpful to emulate multiple inheritance
(http://journal.stuffwithstuff.com/2011/02/21/multiple-inheritance-in-javascript/).
Long story short, with the get and set traps, you can emulate this
multiple inheritance without having the required prototype chain.
However, since
Hi,
I'd like to discuss forwarding proxy patterns. I'll call full handler
a handler with all current traps and own handler a handler with just
the own properties layer traps.
The current forwarding proxy pattern is:
---
var p = Proxy.create(fullForwardingHandler(target));
---
Any interaction with
Le 22/03/2011 12:58, Tom Van Cutsem a écrit :
Another way of solving the inconsistency I see in providing the 6
prototype-climbing traps (getPropertyDescriptor,
getPropertyNames, has, get, set and enumerate) and
protecting Object.getPrototypeOf and instanceof could be to
Le 22/03/2011 13:12, Tom Van Cutsem a écrit :
2011/3/18 David Bruant bru...@enseirb-matmeca.fr
mailto:bru...@enseirb-matmeca.fr
Le 16/03/2011 10:25, Tom Van Cutsem a écrit :
David,
This open issue is indeed one that merits further discussion here.
Some thoughts
Le 22/03/2011 21:42, David Bruant a écrit :
Hi,
About the string_repeat strawman
(http://wiki.ecmascript.org/doku.php?id=strawman:string_repeat), one
alternative solution could be a two argument constructor. Something
like: String(n, pattern). So, for the example in the strawman, it
would
Le 22/03/2011 22:29, Peter van der Zee a écrit :
On Tue, Mar 22, 2011 at 2:39 AM, Dmitry A. Soshnikov
dmitry.soshni...@gmail.com mailto:dmitry.soshni...@gmail.com wrote:
On 22.03.2011 23:42, David Bruant wrote:
Hi,
About the string_repeat strawman
(http
Le 22/03/2011 00:08, David Bruant a écrit :
Hi,
Proxies can be helpful to emulate multiple inheritance
(http://journal.stuffwithstuff.com/2011/02/21/multiple-inheritance-in-javascript/).
Long story short, with the get and set traps, you can emulate this
multiple inheritance without having
the discussion.
Let's see how the proxy inheritance topic goes with discussions and
experiments and we'll be able to answer your question.
Bests,
David
Cheers,
Tom
2011/3/22 David Bruant david.bru...@labri.fr
mailto:david.bru...@labri.fr
Le 22/03/2011 12:58, Tom Van Cutsem a écrit
Le 25/03/2011 20:18, Brendan Eich a écrit :
Dunno. You were ravaged by the Crocken so you may be a bit sore still :-/.
Any list with informal/unsound syntax talk is not one I want to be on. It's
not quite beer talk. It could lead to a breakthrough idea, who knows? But the
cost is pretty
Hi,
I have recently read
http://wiki.ecmascript.org/doku.php?id=strawman:es5_internal_nominal_typing
and in particular Array.isArray should test for presence of special
[[DefineOwnProperty]] rather than testing [[Class] (There is a typo, by
the way) which has woken up one fundamental question
Le 30/03/2011 12:30, David Bruant a écrit :
(...)
Nevertheless even if setting [[Class]] to arrays it wouldn't make them
Arrays just because some string has the right value.
(...)
Nevertheless even if setting [[Class]] to Array it wouldn't make
resulting objects Arrays just because some
.
Is there already a deadline for when proxies have to/should/may be frozen?
On Mar 30, 2011, at 3:30 AM, David Bruant wrote:
(...)
The ES definition of Array.isArray is an example of this. It uses a
[[Class]] test because it wanted array objects imported from different
top level global
Hi,
This proposal is another attempt to address the DOM Element+EventTarget
multiple inheritance issue in ECMAScript.
The main idea of my proposal is to introduce the concept of object
equivalence classes. First off, I'd like to say that I refer to a
concept
[Adding DOMCore to the discussion]
Le 02/04/2011 21:16, Brendan Eich a écrit :
On Apr 2, 2011, at 11:44 AM, David Bruant wrote:
Hi,
This proposal is another attempt to address the DOM Element+EventTarget
multiple inheritance issue in ECMAScript.
That issue was resolved by putting
Le 02/04/2011 21:30, Brendan Eich a écrit :
On Apr 2, 2011, at 12:16 PM, Brendan Eich wrote:
You must mean only in the cases where typeof a == typeof b, then a == b =
a === b, and === is an e.r. But that does not mean == is an e.r.
Forgot typeof a == object above, to be precise.
Indeed, I
Le 02/04/2011 23:40, Brendan Eich a écrit :
On Apr 2, 2011, at 1:58 PM, David Bruant wrote:
I'm surprised by the idea that == could be defined on a per-value
comparison basis on objects (Array as you give it as an example). It
doesn't make the relation last throughout the program lifetime
Le 03/04/2011 02:11, Brendan Eich a écrit :
On Apr 2, 2011, at 4:19 PM, David Bruant wrote:
I have the feeling that none of these can help out with multiple
inheritance. This is the problem I want to address.
Why? I mean, given the WebIDL and DOM changes.
Because people want it; Node
Le 04/04/2011 17:08, Tom Van Cutsem a écrit :
Hi,
2011/3/31 David Bruant david.bru...@labri.fr
mailto:david.bru...@labri.fr
Hi,
First, I'd like to say that I'm glad proxy-related issues have
been discussed during the last TC-39 meeting and that all have
found an agreement
Le 05/04/2011 10:22, Tom Van Cutsem a écrit :
Hi,
I'd like to remind that if Object.getPropertyDescriptorisn't
a native function with a native underlying internal method,
but a monkey patch, it will not call a proxy trap (maybe this
should be addressed?).
(reposting source code from previous message as plain text)
fix: function() {
// As long as target is not frozen, the proxy won't allow itself
to be fixed
if (!Object.isFrozen(this.target))
return undefined;
var props = {};
var handler = this;
Le 05/04/2011 10:22, Tom Van Cutsem a écrit :
(...)
If a browser does not support Object.freeze, seal or
preventExtensions, it likely does not support fixing proxies either.
Calling the fix() trap explicitly via Proxy.trap would still not
lead to the expected behavior.
Thinking about fix and
On Apr 2, 2011, at 5:11 PM, Brendan Eich wrote:
On Apr 2, 2011, at 4:19 PM, David Bruant wrote:
I have the feeling that none of these can help out with multiple
inheritance. This is the problem I want to address.
Why? I mean, given the WebIDL and DOM changes.
Is multiple inheritance
another item to the
list which would be equivalence class.
Cheers,
David
Cheers,
Tom
2011/4/3 Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com
On Apr 2, 2011, at 5:11 PM, Brendan Eich wrote:
On Apr 2, 2011, at 4:19 PM, David Bruant wrote:
I have
Le 07/04/2011 20:39, Brendan Eich a écrit :
On Apr 7, 2011, at 7:49 AM, Tom Van Cutsem wrote:
But again, I would hope that an implementation that supports both
Object.freeze + proxies just supports freezing proxies via the fix() trap as
per the draft spec. I don't see the need for such an
Le 07/04/2011 19:27, Brendan Eich a écrit :
On Apr 5, 2011, at 2:19 PM, David Bruant wrote:
What I'm worried about is the memory cost of such an implementation.
The current [[HasInstance]] implementation has a constant memory
cost. Keeping references has a linear memory cost in terms
Le 10/04/2011 19:24, Axel Rauschmayer a écrit :
As far as I am aware, there is no way to change a property that isn’t at the
beginning of the property chain, because the change will create a new
property there.
Are there plans to change this? It would be nice to have something akin to
Le 10/04/2011 23:27, Dmitry A. Soshnikov a écrit :
On 11.04.2011 18:07, Mark S. Miller wrote:
On Sun, Apr 10, 2011 at 11:21 PM, David Herman dher...@mozilla.com
mailto:dher...@mozilla.com wrote:
I wondered if someone was going to make this point.
That should be
Le 11/04/2011 22:01, Brendan Eich a écrit :
On Apr 11, 2011, at 8:58 PM, David Bruant wrote:
Le 11/04/2011 21:47, Brendan Eich a écrit :
On Apr 11, 2011, at 6:36 PM, Allen Wirfs-Brock wrote:
Personally, I prefer Object.getOwnPropertyDescriptor as a property
existence test because
Hi,
I'd like to share my experience on a recent experiment. First off, I'd
like to apologize for the name; declarative object doesn't really
capture it and may be confusing. Second of all, what I have created
doesn't really solve any use case (I'll discuss it), but offers at most
some syntactic
Le 12/04/2011 18:41, David Bruant a écrit :
Hi,
I'd like to share my experience on a recent experiment. First off, I'd
like to apologize for the name; declarative object doesn't really
capture it and may be confusing. Second of all, what I have created
doesn't really solve any use case (I'll
Le 13/04/2011 10:18, Dmitry A. Soshnikov a écrit :
On 13.04.2011 12:08, David Bruant wrote:
Le 13/04/2011 09:02, Dmitry A. Soshnikov a écrit :
Yes, the pattern is interesting, though, really, which practical
use-case will it have?
I warned from the beginning that I didn't see any :-p
More
Le 13/04/2011 23:24, Sean Eagan a écrit :
One way to get truly shared proxy handlers
Do we want it?
In my previous thread, I discussed shared handlers, but more from a
proxy writer experience point of view, not with the idea of having
something specified toward it. The topic had already been
Le 18/04/2011 21:55, Sean Eagan a écrit :
Storing proxy instance state directly within handlers:
==
Trap namespace pollution:
The default handler, Proxy.Handler, stores proxy instance state
directly in each handler's target
Hi,
harmony:weak_maps defines weak maps as unordered tables mapping objects
to values. It does reminds me objects a lot, but instead of strings,
keys are objects. The API (get/set/has/delete) is very close from what
is already possible with current objects for which we have syntax
constructs for
Le 21/04/2011 02:00, Brendan Eich a écrit :
We're generally against using the same syntax for notably different semantics.
I understand.
The stringification of the key in obj[key] is fundamental to objects. It does
not apply to WeakMaps, so wm[obj] seems like a trap. Sometimes o[x] will
Le 19/04/2011 21:33, Sean Eagan a écrit :
On Mon, Apr 18, 2011 at 7:38 PM, David Bruant david.bru...@labri.fr wrote:
Thus, it seems to me that storing
anything in handlers besides existing traps is likely to cause future
headaches, and should be avoided.
That's an excellent point. It sounds
Le 20/04/2011 17:09, Tom Van Cutsem a écrit :
2011/4/18 Sean Eagan seaneag...@gmail.com mailto:seaneag...@gmail.com
Existing default handler useless to shared handlers:
==
The existing Proxy.Handler.prototype and all
Le 27/04/2011 19:38, Sean Eagan a écrit :
Hi,
The get and set traps currently have both receiver and proxy
arguments. This is because it has been suggested that they are not
the same in the case of property access on a receiver causing a
[[Get]] / [[Put]] call to propogate up the prototype
Le 27/04/2011 20:37, Sean Eagan a écrit :
Hi David,
On Wed, Apr 27, 2011 at 1:17 PM, David Bruant david.bru...@labri.fr wrote:
The case when they are not the same is when the proxy is in the
prototype chain (regardless of what kind of object is underneath).
See the third example at:
https
:
Object.trap(Object.getPrototypeOf(proxy));
}
---
The only exception I can think of is set which may me slightly more
complicated.
On Wed, Apr 27, 2011 at 1:55 PM, David Bruant david.bru...@labri.fr wrote:
Oh ok, sorry. So in that case, this is something that has been discussed
already
Le 27/04/2011 23:09, Sean Eagan a écrit :
As explained before, the existing ES5 semantics would cause the proxy's
getPropertyDescriptor trap to be called thus obtaining any getter
/ setter that the proxy wants. The |this| binding of this getter
/ setter will then be set to the receiver by ES5
Hi,
This is purely an editing issue, but for String.prototype.repeat, Number
is passed as an argument while String isn't.
Following the idea of correctness that Mark Miller used in [1], I
propose to pass neither Number nor String and just to the
Object.defineProperty.
David
[1] :
A couple of things have been discussed and decided related to proxies
during the last TC39 meeting. Notes have been added on the following pages:
http://wiki.ecmascript.org/doku.php?id=strawman:proxy_derived_traps
http://wiki.ecmascript.org/doku.php?id=strawman:handler_access_to_proxy
Le 07/05/2011 02:04, Peter Michaux a écrit :
I'd like to ask when is function too long? I never type it thanks to
my text editor's features so I know it is not too long for developers
with a good editor.
What editor are you using? I have always been disappointed in my
experience with IDEs and
Le 05/05/2011 20:38, Tom Van Cutsem a écrit :
(...)
Also, as you point out, full consistency across all traps is difficult
to guarantee, so does it make sense to enforce consistency for some
traps but not for others? The overall behavior of the proxy may still
be inconsistent.
I do see
1 - 100 of 1196 matches
Mail list logo
