[+Allen]
2013/3/13 Nathan Wall nathan.w...@live.com
However, as a matter of principle, my argument is that
`Object.getOwnPropertyDescriptor` should, at the bare minimum, return a
descriptor that can be known to work in `Object.defineProperty`. If
`Object.defineProperty` doesn't accept it,
Tom Van Cutsem wrote:
[+Allen]
2013/3/13 Nathan Wall nathan.w...@live.com mailto:nathan.w...@live.com
However, as a matter of principle, my argument is that
`Object.getOwnPropertyDescriptor` should, at the bare minimum,
return a descriptor that can be known to work in
Le 14/03/2013 08:51, Tom Van Cutsem a écrit :
[+Allen]
2013/3/13 Nathan Wall nathan.w...@live.com mailto:nathan.w...@live.com
However, as a matter of principle, my argument is that
`Object.getOwnPropertyDescriptor` should, at the bare minimum,
return a descriptor that can be known
On 3/14/2013 2:12 AM, David Bruant wrote:
Le 14/03/2013 08:51, Tom Van Cutsem a écrit :
[+Allen]
2013/3/13 Nathan Wall nathan.w...@live.com
mailto:nathan.w...@live.com
However, as a matter of principle, my argument is that
`Object.getOwnPropertyDescriptor` should, at the bare
Le 14/03/2013 17:01, Brandon Benvie a écrit :
I also mentioned I thought it was unlikely to be commonly used, since
I've never seen it used besides some of my own code (which exists in a
couple libraries used by few or just me).
Sincere apologies on missing an important part of your quote (I
this is an excellent Point Mark, I wish I mentioned this earlier in
redefine.js
For already panicing developers sake, the problem addressed by Mark can be
easily solved going explicitly over the property definition so that this
won't work:
Object.freeze(Object.prototype);
function Point(x, y) {
The way to invoke the default behavior will be to just return
`undefined` from a hook (or fulfill with `undefined` for the fetch
hook).
That's one way to do it. It doesn't allow the overrider to do any
transformation on the result though. If the overrider can explicitly call
the default
On Thu, Mar 14, 2013 at 11:03 AM, Kevin Smith khs4...@gmail.com wrote:
The way to invoke the default behavior will be to just return
`undefined` from a hook (or fulfill with `undefined` for the fetch
hook).
That's one way to do it. It doesn't allow the overrider to do any
transformation
On 3/14/2013 11:03 AM, Kevin Smith wrote:
Also (and this is a separate point), I don't see how in the current
design a CoffeeScript translator could be implemented as a custom
loader. As far as I can tell, all loaders encapsulate their own
module instance table. For CoffeeScript, you want
On 3/14/2013 12:04 PM, Brandon Benvie wrote:
loaderOne.set(mrl, loaderTwo.get())
Sorry, I meant `loaderOne.set(mrl, loaderTwo.get(mrl))`. Assuming their
resolve hooks are the same I guess.
___
es-discuss mailing list
es-discuss@mozilla.org
The more important reason to handle `eval` in a loader is so that if
you're enforcing some invariant on code executed in a specific loader,
you don't want the code to be able to escape that invariant via
`eval`.
This makes sense now. The loader has the opportunity to analyze and
transform
On Thu, Mar 14, 2013 at 2:14 PM, Kevin Smith khs4...@gmail.com wrote:
So it's really more of a transform hook than a translate hook. Would
naming it transform would make the intention more obvious?
Transformations of languages are translations, so I think that
`translate` is clearer. CS - JS
So it's really more of a transform hook than a translate hook. Would
naming it transform would make the intention more obvious?
Transformations of languages are translations, so I think that
`translate` is clearer. CS - JS is a translation.
Sure, but to me translate implies translation
Consider:
var i = getSomeIterator();
var x0 = i.next(), x1 = i.next(), x2 = i.next();
for (let x of i) {
...
}
Should the loop iterate over x0, x1, and x2? That's what would (have to)
happen if i[@iterator]() returned a cloneof the iterator ireset to the
starting
On 14 March 2013 22:54, Brendan Eich bren...@mozilla.com wrote:
Consider:
var i = getSomeIterator();
var x0 = i.next(), x1 = i.next(), x2 = i.next();
for (let x of i) {
...
}
Should the loop iterate over x0, x1, and x2? That's what would (have to)
happen if
Andreas Rossberg wrote:
On 14 March 2013 22:54, Brendan Eichbren...@mozilla.com wrote:
Consider:
var i = getSomeIterator();
var x0 = i.next(), x1 = i.next(), x2 = i.next();
for (let x of i) {
...
}
Should the loop iterate over x0, x1, and x2? That's what would
On 8 March 2013 18:23, Jason Orendorff jason.orendo...@gmail.com wrote:
On Thu, Mar 7, 2013 at 1:05 PM, Andreas Rossberg rossb...@google.com
wrote:
On 7 March 2013 18:30, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Zip's informal contract should state that if iterators are passed as
On 14 March 2013 23:38, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
That leaves my original proposal not to have generator application
return an iterator, but only an iterable. Under that proposal, your
example requires disambiguation by inserting the intended call(s) to
Andreas Rossberg wrote:
On 14 March 2013 23:38, Brendan Eichbren...@mozilla.com wrote:
Andreas Rossberg wrote:
That leaves my original proposal not to have generator application
return an iterator, but only an iterable. Under that proposal, your
example requires disambiguation by inserting
Andreas Rossberg wrote:
See my reply to Jason: I think that in most practical cases (in
particular, all abstractions over iterables), the invocation of the
iterator method will happen inside an abstraction, and the programmer
does not have to worry about it.
Talking 1:1 with you after the TC39
On Thu, Mar 14, 2013 at 3:48 PM, Andreas Rossberg rossb...@google.comwrote:
On 8 March 2013 18:23, Jason Orendorff jason.orendo...@gmail.com wrote:
and you definitely don't want new state here, because what would that
even
mean? A read position is kind of inherent to a file descriptor,
On 15 March 2013 02:33, Jason Orendorff jason.orendo...@gmail.com wrote:
On Thu, Mar 14, 2013 at 3:48 PM, Andreas Rossberg rossb...@google.com
wrote:
On 8 March 2013 18:23, Jason Orendorff jason.orendo...@gmail.com wrote:
and you definitely don't want new state here, because what would that
On 15 March 2013 01:13, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
See my reply to Jason: I think that in most practical cases (in
particular, all abstractions over iterables), the invocation of the
iterator method will happen inside an abstraction, and the programmer
23 matches
Mail list logo
