I'm a bit puzzled regarding the meaning of use strict in the context
of higher-order uses of eval.
Consider the following program. What is the expected result of the latter calls?
-
var x = 3
function call_eval() { x = 3; eval(var x = 4); return x }
function
Thanks to everybody for clearing up my confusion. The thing I had
missed in the spec was Section 10.4.2. And of course, my example was
too simplistic because it couldn't distinguish caller and global
context.
At the risk of reviving old discussions, are there any sources
explaining the rationale
On 11 May 2011 20:30, Mark S. Miller erig...@google.com wrote:
On Wed, May 11, 2011 at 10:31 AM, Andreas Rossberg rossb...@google.com
wrote:
On 11 May 2011 18:31, Mark S. Miller erig...@google.com wrote:
On Wed, May 11, 2011 at 4:42 AM, Andreas Rossberg rossb...@google.com
wrote
On 11 May 2011 23:15, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Direct eval (or the eval operator, as Oliver refers to it) is a way to
(mostly) statically identify eval calls and to do special case processing to
make the caller environment information available for eval processing.
On 12 May 2011 17:47, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On May 12, 2011, at 2:10 AM, Andreas Rossberg wrote:
The one bit where these questions are somewhat related is the
(mostly) bit in your reply. Is there a reason for this mostly,
which, I would argue, is a form of dynamic
, Andreas Rossberg rossb...@google.com
wrote:
On 13 May 2011 01:50, Mark S. Miller erig...@google.com wrote:
Assume that
- we distinguish two variants of the eval function, strict and
non-strict -- let's call these values EVAL_s and EVAL_ns.
- initially (in global scope), the identifier
Separating out the functionality of abstract names certainly is a good idea.
But is there any reason to make it a method of Object? In essence,
private names form a new primitive type, so there should be a separate
global object or module for them. Assuming for a minute it was called
Name (which
On 18 May 2011 18:27, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
In general, it is a good idea to avoid new global names that aren't going to
be in modules. In particular, there is no particular reason these factory
methods shouldn't be visible via the Harmony ES5 global object. In that
My apologies if this has been discussed to death before -- well,
actually, I'd be surprised if it hasn't (pointers would be welcome).
I think it is worth noting that the baroque notation for defining
constructors that we see in the C++ / Java / C# world primarily is an
artefact of the desire to
On 19 May 2011 15:36, Mark S. Miller erig...@google.com wrote:
Hi Andreas, yes we have a long history of consider this shape, in fact much
longer than the current shape. The final state of proposals along these
lines is
On 19 May 2011 16:05, David Herman dher...@mozilla.com wrote:
Yes, we've talked about this. One of the issues I don't know how to resolve
is if we want to allow the specification of class properties aka statics,
then those need *not* to be in the scope of the constructor arguments, which
On 19 May 2011 17:09, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Hm, making name creation a method of String seems equally odd --
unless you also plan to have typeof String.createPrivateName() ==
string.
That is indeed the plan in the particular version of the proposal that
started this
On 21 May 2011 01:16, felix feli...@gmail.com wrote:
how about the fish operator , easy to type.
Whow, apparently, you are not cursed with a German keyboard. ;)
Seriously, easy to type is an argument that is highly subjective to
i18n-related concerns. The majority of JS programmers does not
On 20 May 2011 18:00, David Herman dher...@mozilla.com wrote:
I think modules are a construct that evaluates to an object is the wrong
way to think about them. Syntactic modules are a second-class construct that
is not an expression. You can reflect on modules at runtime, and that
either.
/Andreas
On May 20, 2011 7:58 AM, Andreas Rossberg rossb...@google.com wrote:
On 19 May 2011 16:05, David Herman dher...@mozilla.com wrote:
Yes, we've talked about this. One of the issues I don't know how to
resolve is if we want to allow the specification of class properties aka
On 23 May 2011 19:42, Mark S. Miller erig...@google.com wrote:
On Mon, May 23, 2011 at 2:16 PM, Andreas Rossberg rossb...@google.com
wrote:
Compare:
class Point {
private x, y
constructor(x0, y0) { x = x0; y = y0 }
public function move(dx, dy) { x += dx; y += dy }
public
On a somewhat related note, I recently noticed that the semantics of
[[GetProperty]] and [[GetOwnProperty]], according to
http://wiki.ecmascript.org/doku.php?id=harmony:proxies_semantics,
contain a possible reject step, which doesn't seem to be
well-defined given that these method have no Throw
I'm puzzled about this idea. I thought that one of the main design
goals of proxies was that they are transparent, i.e. you cannot tell a
proxy apart from a proper object. How can this be maintained for
Proxy.createFrom? AFAICS, there is no way you can perform this
operation on an object that
Is it too late to incorporate errata for 5.1 already? :)
It seems that the algorithm specified in 10.5 is wrong. In order to
make sense, and match the informal description at the beginning of
Section 10.6, step 8 needs to take place before step 6. (Noticed by
Steven Keuchel.)
/Andreas
I believe there is some type confusion in the proxy proposal spec
wrt property descriptors and their reification into attributes
objects.
1. In a note on the def of [[DefineOwnProperty]] for proxies, the proposal says:
The Desc argument to this trap is a property descriptor object
validated by
On 1 July 2011 12:12, Andreas Rossberg rossb...@google.com wrote:
I believe there is some type confusion in the proxy proposal spec
wrt property descriptors and their reification into attributes
objects.
1. In a note on the def of [[DefineOwnProperty]] for proxies, the proposal
says
by any?
Is it Object.keys(desc)?
Object.enumerate(desc) (I mean the prop list enumerated over with for-in)?
Object.getOwnPropertyNames(desc)?
David
[1] https://github.com/DavidBruant/PropStackObjects (see the HTMLs to
see how it works)
Le 01/07/2011 14:54, Andreas Rossberg a écrit :
On 1
? That seems to be the only place where additional objects can
occur, or am I wrong?
Cheers,
/Andreas
2011/7/1 Andreas Rossberg rossb...@google.com
On 1 July 2011 12:12, Andreas Rossberg rossb...@google.com wrote:
I believe there is some type confusion in the proxy proposal spec
wrt property
.
/Andreas
2011/7/2 Andreas Rossberg rossb...@google.com
Hi Tom.
On 2 July 2011 13:50, Tom Van Cutsem tomvc...@gmail.com wrote:
Hi Andreas,
First, you're right about the typing issue:
In ES5, for values of type Object, the signature for
[[DefineOwnProperty]]
would
On 7 July 2011 13:11, Tom Van Cutsem tomvc...@gmail.com wrote:
2011/7/6 Andreas Rossberg rossb...@google.com
While putting together some test cases for Object.keys, I wondered: is
it intended that property names are always passed to traps as strings?
That is indeed the intent.
It seems
On 7 July 2011 14:32, David Bruant david.bru...@labri.fr wrote:
However, if we assume that the getOwnPropertyNames trap is able to do type
coercion on its output, there is no reason for the keys trap to not do that
too, regardless of how it was implemented.
Yes, that's what I would propose,
On 7 July 2011 15:09, David Bruant david.bru...@labri.fr wrote:
Yes, that's what I would propose, too. It's just a bit ugly that we
have to do that in two places now.
Three if counting the enumerate trap for for-in loops. Regardless of
ugliness, it's necessary. keys and enumerate are derived
On 7 July 2011 16:12, David Bruant david.bru...@labri.fr wrote:
Derived traps as showed are written in JS for expository purposes.
Engines
will be free to optimize as they wish internally as long as the observed
behavior is the same.
True, but optimizing that actually is more tricky than you
On 7 July 2011 17:58, Brendan Eich bren...@mozilla.com wrote:
On Jul 7, 2011, at 8:32 AM, Andreas Rossberg wrote:
On 7 July 2011 16:12, David Bruant david.bru...@labri.fr wrote:
Derived traps as showed are written in JS for expository purposes.
Engines
will be free to optimize as they wish
On 7 July 2011 19:35, David Bruant david.bru...@labri.fr wrote:
No, with the current keys default trap (calling
this.getOwnPropertyNames()) there is no double conversion. Only one at
the exit of the keys trap. There would be 2 conversions if the keys
trap had the proxy argument (based on
of defineProperties to go through defineProperty,
instead of calling the internal [[DefineOwnProperty]] directly.
/Andreas
On 6 July 2011 14:55, Andreas Rossberg rossb...@google.com wrote:
On 3 July 2011 13:29, Tom Van Cutsem tomvc...@gmail.com wrote:
Comments?
Looks good to me. I agree
attributes on descriptor objects. That is, we should either support
such attributes properly, i.e. have them consistently flow both ways
(from clients to traps and vice versa). Or we do not support them at
all, i.e. filter them out everywhere.
/Andreas
On 8 July 2011 10:59, Andreas Rossberg rossb
On 8 July 2011 21:16, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
The current versions of the private names proposal
http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects simply
exposes a constructor for creating unique values can be be used as property
keys:
Of the several
On 9 July 2011 00:24, Brendan Eich bren...@mozilla.com wrote:
On Jul 8, 2011, at 2:43 PM, Andreas Rossberg wrote:
One minor suggestion I'd have is to treat names as a proper new
primitive type, i.e. typeof key == name, not object. That way, it
can be defined much more cleanly what a name
On 10 July 2011 22:23, David Herman dher...@mozilla.com wrote:
Another common and useful fusion of two traversals that's in many Schemes is
map-filter or filter-map:
a.filterMap(f) ~~~ [res for [i,x] of items(a) let (res = f(x, i)) if (res
!== void 0)]
I rather arbitrarily chose to
On 9 July 2011 14:42, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
Unlike Names, strings and numbers are forgeable, so if they were
allowed as keys in WeakMaps, the associated value could never be
safely collected. Names, by contrast, have identity.
Of course you are right, and I shouldn't
On 9 July 2011 17:48, Brendan Eich bren...@mozilla.com wrote:
Adding names as a distinct reference and typeof type, extending
WeakMap to have as its key type (object | name), adds complexity
compared to subsuming name under object.
It seems to me that you are merely shifting the additional
I fully agree that isProxy sounds like a bad idea. It just breaks the
proxy abstraction.
/Andreas
On 13 July 2011 10:26, Andreas Gal g...@mozilla.com wrote:
I really don't think IsProxy is a good idea. It can lead to subtle bugs
depending on whether an object is a DOM node, or a wrapper
'this.defineProperty' rather than 'Object.defineProperty(proxy,...)'.
2011/7/7 Andreas Rossberg rossb...@google.com
On 7 July 2011 19:35, David Bruant david.bru...@labri.fr wrote:
No, with the current keys default trap (calling
this.getOwnPropertyNames()) there is no double conversion. Only
tampered, not hampered, of course...
On 14 July 2011 12:52, Andreas Rossberg rossb...@google.com wrote:
Very much appreciated. Given all the nasty mutability in JS, I think
for the non-normative JS implementations you also might want to note
that it assumes that nobody has hampered
On 28 July 2011 10:35, David Bruant david.bru...@labri.fr wrote:
Le 28/07/2011 06:21, Brendan Eich a écrit :
== Handler access to proxies ==
Proxy handler traps need to receive the proxy as a parameter: first, or
last?
Last allows trap implementors to leave |proxy| off. It's also a
On 28 July 2011 20:34, David Bruant david.bru...@labri.fr wrote:
Le 28/07/2011 19:52, Andreas Rossberg a écrit :
On 28 July 2011 10:35, David Bruant david.bru...@labri.fr wrote:
Le 28/07/2011 06:21, Brendan Eich a écrit :
== Handler access to proxies ==
Proxy handler traps need to receive
On 29 July 2011 19:08, Brendan Eich bren...@mozilla.com wrote:
I did not mean multimethods (generic functions is a confusing term, since
it also means functions that work for parameters of any time; also generic
suggests generics, i.e. type parameters).
Generic is a heavily overloaded term.
On 4 August 2011 22:57, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Using these two new ideas and other active object literal enhancement
proposals it is pretty easy to compose a class-like declaration. For
example the SkinnedMesh from
the
On 4 August 2011 19:34, Brendan Eich bren...@mozilla.com wrote:
On Jul 31, 2011, at 1:04 PM, Sean Eagan wrote:
A 'receiver' argument is not needed because it would never be
different than the proxy, and the proxy can either be passed as an
argument or stored either as an own property of the
On 8 August 2011 18:46, Kevin Reid kpr...@google.com wrote:
On Mon, Aug 8, 2011 at 08:50, Andreas Rossberg rossb...@google.com wrote:
I would welcome removing the extra receiver (or proxy) arguments from
get and set traps. However, it seems to me that the main reason,
currently, for having
On 9 August 2011 19:25, Kevin Reid kpr...@google.com wrote:
On Tue, Aug 9, 2011 at 01:17, Andreas Rossberg rossb...@google.com wrote:
On 8 August 2011 18:46, Kevin Reid kpr...@google.com wrote:
On Mon, Aug 8, 2011 at 08:50, Andreas Rossberg rossb...@google.com wrote:
Arguably, making a proxy
On 12 August 2011 13:53, Tom Van Cutsem tomvc...@gmail.com wrote:
I think I found a compelling and easy-to-understand
rule for determining whether or not a trap needs access to proxy/receiver:
if the trap deals with inherited properties, it needs access to |proxy|.
Using that rule, the
On 17 August 2011 21:24, John-David Dalton john.david.dal...@gmail.com wrote:
Another odd thing is that V8 uses the `Array#push` internally for
`Object.defineProperties`.
I noticed that if I set `Array.prototype.push = 1;` using
`Object.defineProperties(…)` would error complaining about `push`
We are currently in the process of implementing block scoping for V8
(http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_bindings).
Brendan and Dave suggest that certain combinations of `let' and `var'
should be an error (more precisely, a syntax error, I assume).
However, there are
On 23 August 2011 19:14, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Aug 23, 2011, at 5:31 AM, Andreas Rossberg wrote:
We are currently in the process of implementing block scoping for V8
(http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_bindings).
The wiki page spec
On 23 August 2011 21:18, Brendan Eich bren...@mozilla.com wrote:
I think the rules we have discussed are:
1. Any hoisting of var across let binding the same name (whether explicit, or
as in catch blocks and comprehensions, implicit) is an early error.
2. Redeclaration of a name in the same
That's not to say that I couldn't live with more fine-grained rules, I
just don't consider them worthwhile. Ultimately, we want to morally
deprecate var for Harmony mode, so introducing too many extra rules
around it seems a bit unjustified, unless there is a very good reason.
Btw, we had
On 24 August 2011 01:07, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Also there can be real problems with exposing too much program metadata
directly to the application layer. I've had lots of experience with Smalltalk
environments where this was the case and it leads to a muddling of the
On 24 August 2011 18:03, Brendan Eich bren...@mozilla.com wrote:
On Aug 24, 2011, at 2:03 AM, Andreas Rossberg wrote:
On 23 August 2011 21:18, Brendan Eich bren...@mozilla.com wrote:
I think the rules we have discussed are:
1. Any hoisting of var across let binding the same name (whether
On 25 August 2011 18:57, Brendan Eich bren...@mozilla.com wrote:
On Aug 25, 2011, at 6:17 AM, Andreas Rossberg wrote:
There is no before and after or both here. Hoisting first, with rule 1
enforced; then rule 2 checking. Relative source order of declarations is
irrelevant.
pedanticWell
On 27 August 2011 00:34, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Something we need to define for ES.next is how to compute the length
property value for functions whose formal parameter list includes optional
and/or rest parameters.
True, and actually, there are more issues with length
On 29 August 2011 01:36, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Aug 27, 2011, at 6:12 AM, Andreas Rossberg wrote:
True, and actually, there are more issues with length function
proxies. I don't have my notes with me right now, but for example, it
is not clear at all what length
On 30 August 2011 18:41, David Bruant david.bru...@labri.fr wrote:
This would facilitate the author work when it comes to creating functions
that look like functions without having to always include some
initialization code for .length, .prototype and such.
It will still be possible to
On 31 August 2011 15:21, Tom Van Cutsem tomvc...@gmail.com wrote:
I coded up a hypothetical Proxy.createConstructor function that creates a
function proxy initialized according to ES5.1 section 13.2:
https://gist.github.com/1183514
Nit: invoking callTrap.call assumes that callTrap has an
On 4 September 2011 21:45, Brendan Eich bren...@mozilla.com wrote:
On Sep 6, 2011, at 1:52 PM, Dmitry Soshnikov wrote:
(1) to standardize `toString` (for this particular case -- do not remove
comments inside);
If the (1) is not possible (why by the way?),
Because comments are not saved
On 13 September 2011 09:33, Brendan Eich bren...@mozilla.com wrote:
You are simply way out of date on JS optimizing VMs, which (based on work
done with Self and Smalltalk) all now use hidden classes aka shapes and
polymorphic inline caching to optimize to exactly the pseudo-assembly you
On 15 September 2011 09:10, Brendan Eich bren...@mozilla.com wrote:
On Sep 14, 2011, at 11:09 PM, Allen Wirfs-Brock wrote:
I would prefer ObjectMap (the keys are restricted to objects).
Now that you point it out (again), I agree.
I don't. :) It is true to some extent that WeakMap is GC
On 13 September 2011 16:48, Brendan Eich bren...@mozilla.com wrote:
On Sep 13, 2011, at 5:33 AM, Andreas Rossberg wrote:
* There are extra costs in space and time to doing the runtime analysis.
* Compile time is runtime, so there are severe limits to how smart you
can afford to get
On 13 September 2011 21:32, Wes Garland w...@page.ca wrote:
When I write shell programs, and JS programs, I keep an extra terminal
window open to a spare shell or a JS REPL. I try stuff. Stuff that works, I
copy into my program. Then I run my program - which happens quickly,
because the
On 14 September 2011 00:00, Brendan Eich bren...@mozilla.com wrote:
So, static+dynamic. The static side has some powerful algorithms to bring to
bear. Dynamic is necessary due to eval and kin, and gives strictly more
information (and more relevant information!).
Nitpick: I believe you are
On 15 September 2011 17:47, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
No the normal use case for WeakMaps is simply to make associations between
objects and arbitrary values. The special GC behavior is necessary to avoid
memory leaks, but that is a quality of implementation issue, not a
On 16 September 2011 02:12, Mike Shaver mike.sha...@gmail.com wrote:
On Thu, Sep 15, 2011 at 9:02 AM, Andreas Rossberg rossb...@google.com wrote:
On 14 September 2011 00:00, Brendan Eich bren...@mozilla.com wrote:
So, static+dynamic. The static side has some powerful algorithms to bring
On 16 September 2011 13:52, David Bruant david.bru...@labri.fr wrote:
Furthermore, let imagine for a minute that i need an ECMAScript
implementation for programs i write which i know (for some reason) all are
short live and use a maximum finite amount of memory i know. Based on this
knowledge
[Forgot the list.]
-- Forwarded message --
From: Andreas Rossberg rossb...@google.com
Date: 16 September 2011 15:35
Subject: Re: {Weak|}{Map|Set}
To: David Bruant david.bru...@labri.fr
On 16 September 2011 15:17, David Bruant david.bru...@labri.fr wrote:
Well yes, but that's
On 16 September 2011 19:42, Mark S. Miller erig...@google.com wrote:
Does anyone see anything wrong with EphemeralMap?
Yes. It's a longish name, and one that I will never be able to
remember how to spell correctly. And to most programmers it probably
sounds about as reassuring as endofunctor or
.
But I'll leave it at that, nobody wants another longish bike-shedding
discussion.
On 16 September 2011 18:50, David Bruant david.bru...@labri.fr wrote:
Changing the subject to something more relavant.
Le 16/09/2011 15:36, Andreas Rossberg a écrit :
On 16 September 2011 15:17, David
Hi Mark, Tom!
I understand that you are currently working on finalizing a number of
aspects of the proxies proposal, so I thought I'd send my current
notes on issues I discovered. (Sorry if I'm a bit late with that, but
I just returned from travelling.)
Here is a list of minor issues. I'll send
Proxies invalidate one fundamental assumption of the current ES spec,
namely that (most) internal methods are effectively pure. That has a
couple of consequences which the current proxy proposal and semantics
seem to ignore, but which we need to address.
OBSERVABILITY EFFICIENCY
In ES5,
On 5 October 2011 18:57, Andreas Rossberg rossb...@google.com wrote:
FIXING PROXIES
A particularly worrisome side effect is fixing a proxy. The proxy
semantics contains a lot of places saying If O is a trapping proxy,
do steps I-J. However, there generally is no guarantee that O remains
On 6 October 2011 06:34, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Oct 5, 2011, at 9:57 AM, Andreas Rossberg wrote:
In summary, I'm slightly worried. The above all seems fixable, but is
that all? Ideally, I'd like to see a more thorough analysis of how the
addition of proxies affects
On 5 October 2011 21:00, Andreas Rossberg rossb...@google.com wrote:
On 5 October 2011 18:57, Andreas Rossberg rossb...@google.com wrote:
FIXING PROXIES
A particularly worrisome side effect is fixing a proxy. The proxy
semantics contains a lot of places saying If O is a trapping proxy,
do
On 7 October 2011 17:47, David Herman dher...@mozilla.com wrote:
I don't think we can get away with repurposing _ as a pattern sigil, since
it's already a valid identifier and used by popular libraries:
http://documentcloud.github.com/underscore/
In my strawman for pattern matching, I
On 10 October 2011 15:38, Tom Van Cutsem tomvc...@gmail.com wrote:
This point was previously noted, see:
http://wiki.ecmascript.org/doku.php?id=strawman:proxy_set_trap
It was brought up at the March 2011 meeting, and IIRC we were in agreement
that the spec. should be adapted to remove the
On 11 October 2011 20:49, Tom Van Cutsem tomvc...@gmail.com wrote:
Proxy.create{Function} is now present on
http://wiki.ecmascript.org/doku.php?id=harmony:proxies_semantics. Let us
know if you spot any further holes.
Great, thanks!
One comment only:
1. Let handler be ToObject(O)
I wonder,
On 12 October 2011 11:00, Andreas Rossberg rossb...@google.com wrote:
On 11 October 2011 20:49, Tom Van Cutsem tomvc...@gmail.com wrote:
Proxy.create{Function} is now present on
http://wiki.ecmascript.org/doku.php?id=harmony:proxies_semantics. Let us
know if you spot any further holes.
Great
On 12 October 2011 02:32, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
The experiments are shown
in http://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aspecification_draftscache=cachemedia=harmony:11.1.5-alternatives.pdf
This contains four versions of section 11.5.1 (Object literals).
On 12 October 2011 18:34, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
http://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aspecification_draftscache=cachemedia=harmony:11.1.5-alternatives-2.pdf
has a 5th alternative version that follows your suggested structure. Note
that I classified
On 18 October 2011 17:08, David Bruant bruan...@gmail.com wrote:
Ok for typeof. But there are other places where [[Call]] is used and the
proxy is expected to (indirectly) expose it. For instance bind:
-
var fpb = Function.prototype.bind;
var bind = fpb.bind(fpb);
var p =
On 18 October 2011 17:48, Tom Van Cutsem tomvc...@gmail.com wrote:
2011/10/18 Andreas Rossberg rossb...@google.com
First, Proxy.startTrapping (a.k.a. Proxy.attach). As far as I can see,
this implies a significantly more general 'become' operation than the
current semantics. I don't see how we
On 19 October 2011 05:08, David Herman dher...@mozilla.com wrote:
It’s still as easy to create such “virtual” proxies: just pass a fresh
empty object (or perhaps even null?)
Please, make it null. So much more pleasant (and avoids needless
allocation).
(The only downside of allowing null to
One concern might be that we probably cannot make arrow notation (if
we introduce it) a primary expression, and it might be confusing if
they have different precedence.
I also think it is easier to parse for the human reader when he sees
(function f() { ... })()
instead of
function f() {
On 22 October 2011 01:08, Axel Rauschmayer a...@rauschma.de wrote:
Reified names (private or otherwise) are a very powerful mechanism. I’m not
aware of another programming language that does this (possibly Common Lisp
with its symbols, but I don’t know enough about them). It’s good to have
On 26 October 2011 20:27, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
1) arguments is needed for backwards compatability (no migration tax)
2) it is useful with destructing parameters:
function ({a,b,c}, [x,y]) {
if (arguments.length 2) ...
...
var arg1obj = argruments[0];
On 27 October 2011 13:35, David Bruant bruan...@gmail.com wrote:
+1. Where the spec is already almost pseudo-code, its readability would
improve if it was, in fact, pseudo-code. But would an extra interpreter be
needed or couldn’t one just implement the ES-262 constructs (execution
contexts
On 3 November 2011 01:12, David Herman dher...@mozilla.com wrote:
ES6 modules are not extensible, for a number of reasons including
compile-time variable checking. But of course API evolution is critical, and
it works; it just works differently. Monkey-patching says let the polyfill
add the
On 5 November 2011 17:44, Brendan Eich bren...@mozilla.com wrote:
Destructuring is irrefutable in that it desugars to assignments from
properties of the RHS. It is not typed; it is not refutable
I don't think that's true, at least not in the usual sense of
irrefutable pattern. Because you can
On 5 November 2011 19:55, Brendan Eich bren...@mozilla.com wrote:
On Nov 5, 2011, at 9:38 AM, Allen Wirfs-Brock wrote:
In a similar vain, what is the value of r in:
let [z,y,...r] = {0:0, 1:1, 2:2, length: 3, 3:3,4:4};
should it be [2] or [2,3,4] (and if the latter how is that determined)?
On 7 November 2011 17:07, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
let {x} = 666
which will be refuted, by raising a TypeError.
No,
It does ToObject(666) and then looks for the x property of the resulting
wrapper object.
Ouch, really? I don't see that in the proposal
On 7 November 2011 17:34, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
It is just another way to
silently inject an `undefined' that is tedious to track down. We
already have too many of those...
It is how the language currently behaves in all situations where an object is
needed but a
On 7 November 2011 18:42, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
or
let [first,second] = abc;
Yes, that's a more convincing example -- although we should probably
be aware that users will then also do
let [x, y, ...s] = somestring
and expect it to slice a string efficiently.
On 7 November 2011 22:46, Brendan Eich bren...@mozilla.com wrote:
On Nov 7, 2011, at 3:04 AM, Andreas Rossberg wrote:
One possible semantics could be treating
let [x, y, z, ...r] = e
as equivalent to
let {0: x, 1: y, 2: z, ..._r} = e
let r = [].slice.call(_r, 3)
where I assume
On 7 November 2011 16:54, Tom Van Cutsem tomvc...@gmail.com wrote:
I wrote up an initial (but fairly complete) draft of a proposed refactoring
of the ES5 [[Get]], [[Put]] and [[HasProperty]] algorithms to change the way
in which these algorithms climb the prototype
chain:
On 8 November 2011 18:47, David Bruant bruan...@gmail.com wrote:
Given that direct proxies are not in a position to violate any of the
*non-configurability or non-extensibility constraints* of their wrapped
target, it should be safe to replace an existing normal object by a
direct proxy
On 8 November 2011 20:29, Andreas Rossberg rossb...@google.com wrote:
On 8 November 2011 18:47, David Bruant bruan...@gmail.com wrote:
Given that direct proxies are not in a position to violate any of the
*non-configurability or non-extensibility constraints* of their wrapped
target, it should
1 - 100 of 778 matches
Mail list logo