A common pattern is to require some sort of data (like date format), even if
you don't have enough information. The missing-data-so-end-up-at-root is a
similar sort of scenario. Many applications have the information they
provide. If we can't get a value from that, they're sunk because they
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
Thanks for noticing. I had already fixed the same code in the default
forwarding handler wiki page, but forgot about the example code on the
proxies page. It's fixed now.
2011/1/26 David Bruant bru...@enseirb-matmeca.fr
Hi,
In getOwnPropertyDescriptor and getPropertyDescriptor traps of the
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 and write these traps as methods of some
sort of default handler as we did for the other derived traps
Note that passing the proxy means that a shared handler object can do caching
or other discrimination based upon the proxy it is being invoked on. For
example, the getPropertyDescriptor implementation shown below could have a
cache to avoid repeated proto chain chasing.
Adding the proxy
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 and write these traps as methods of some sort
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 and
CommonJS Modules 1.1 allows this kind of construct in module code:
var a;
if (someCondition) {
a = require(a1);
} else {
a = require(a2);
}
and the module a1 is not actually evaluated until execution reaches
the a = require(a1) call.
1) Could something like this work in Simple Modules?
Would people be interested in a teleconference call, say Friday to discuss
this further (in case posting to the list doesn't resolve conflicts soon)?
I can make the arrangements...
26. јануар 2011. 01.35, Shawn Steele shawn.ste...@microsoft.com је
написао/ла:
A common pattern is to require
The es strawman was not updated with the recent discussion. I can do that
before the call, and put both versions there. Shawn could check if my
representation matches his proposal...
26. јануар 2011. 13.03, Phillips, Addison addi...@lab126.com је
написао/ла:
Sure.
Did someone update the
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 get the
On Wed, Jan 26, 2011 at 2:04 PM, James Burke jrbu...@gmail.com wrote:
CommonJS Modules 1.1 allows this kind of construct in module code:
var a;
if (someCondition) {
a = require(a1);
} else {
a = require(a2);
}
and the module a1 is not actually evaluated until execution reaches
the
I assume you mean m.load(la1).
So what is the behavior if you do new m.load(la1).Foo() if you know Foo is an
exported object? Is there a module API that allows one to introspect a modules
content?
On Jan 26, 2011, at 1:46 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Wed, Jan 26, 2011
On Jan 26, 2011, at 1:54 PM, Kam Kasravi wrote:
I assume you mean m.load(la1).
What is m?
Where did la1 come from?
Confusion.
So what is the behavior if you do new m.load(la1).Foo() if you know Foo is
an exported object?
Sam addressed that directly (nothing is statically known), cited
You can use module loaders to do exactly this (I believe, based on my
understanding of CommonJS). It would look like:
var ml = ... the desired module loader ...
var a;
if (someCondition) {
a = ml.load(a1);
} else {
a = ml.load(a2);
}
Correction: you have to use callbacks for dynamic
On Jan 26, 2011, at 4:04 PM, Brendan Eich wrote:
On Jan 26, 2011, at 1:54 PM, Kam Kasravi wrote:
So what is the behavior if you do new m.load(la1).Foo() if you know Foo is
an exported object?
Sam addressed that directly (nothing is statically known), cited in full
below.
Oh, I
We avoid freeze-didacticism in general ;-) -- is there a strong reason to
freeze in this example?
/be
On Jan 26, 2011, at 2:51 PM, David Bruant wrote:
Le 26/01/2011 22:31, Brendan Eich a écrit :
On Jan 26, 2011, at 11:02 AM, David Bruant wrote:
On the question of proxy parameters for all
I understand why callbacks are required for module loaders given they fetch
asynchronously, though it's too bad this isn't more tightly integrated with an
eventing model where events could be published when modules are loaded. I
imagine TC39 has no interest in broaching an event system per se,
On Jan 26, 2011, at 3:25 PM, Kam Kasravi wrote:
Are you guys following modules 2.0 at all that seems to be a parallel
universe of sorts under co mmonjs? Seems like it should make the strawman in
some form
I'm reading CommonJS when I have time.
This point has been made before:
I made quick update - could you take a look if I captured the essentials
(there are 2 proposals)?
http://wiki.ecmascript.org/doku.php?id=strawman:i18n_api#proposal_1_shawns
I tried to get examples to show best and worst cases for both approaches -
update if you can do worse :).
26. јануар 2011.
I've removed the old content. It needs more work - like comments, some
properties, return values, but the API is there as proposed in the last
meeting.
Please edit if you find errors.
Shall we meet Friday, 3pm? I'll send details (bridge and pin) tomorrow.
26. јануар 2011. 16.17, Shawn Steele
21 matches
Mail list logo
