On 11 October 2012 09:32, Brendan Eich bren...@mozilla.org wrote:
Tom Van Cutsem wrote:
- Proxy.revocable returns a tuple {proxy, revoke}. While more cumbersome
to work with (especially in pre-ES6 code without destructuring), this API
gets the authority to revoke a proxy exactly right: at
On 11 October 2012 13:41, Mark S. Miller erig...@google.com wrote:
On Thu, Oct 11, 2012 at 4:25 AM, Andreas Rossberg rossb...@google.com
wrote:
On 11 October 2012 09:32, Brendan Eich bren...@mozilla.org wrote:
Tom Van Cutsem wrote:
- Proxy.revocable returns a tuple {proxy, revoke}. While
On 11 October 2012 17:49, John J Barton johnjbar...@johnjbarton.com wrote:
Script is not neutral but neither is Program plus it's just wrong.
The language needs a name for both the unit of compilation and the
assembly of those units. The latter is a program right? So the former
needs a
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 adequate? Frankly, I
completely disagree, because
On 6 November 2012 20:55, David Herman dher...@mozilla.com wrote:
- a way to create promises that don't expose their internal resolve me
methods, etc. so they can be delivered to untrusted clients, e.g.:
var [internalView, externalView] = Promise.makePair();
resolve in internalView
On 7 November 2012 17:57, Tom Van Cutsem tomvc...@gmail.com wrote:
While we're talking nomenclature: the terms promise and future also
appear, with roughly the semantics described by Andreas in Scala's API [1]
and Clojure's API [2] (both very recent APIs). I know MarkM dislikes the use
of
On 12 November 2012 02:17, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
It isn't clear to me why the [[HasOwnProperty]] internal method and the
hasOwn Proxy trap need to exist as object behavior extension points.
Within my current ES6 draft, [[HasOwnProperty]] is only used within the
On 7 November 2012 22:19, Mark S. Miller erig...@google.com wrote:
On Wed, Nov 7, 2012 at 11:12 AM, Andreas Rossberg rossb...@google.com
wrote:
On 7 November 2012 17:57, Tom Van Cutsem tomvc...@gmail.com wrote:
While we're talking nomenclature: the terms promise and future also
appear
On 12 November 2012 16:43, Mark S. Miller erig...@google.com wrote:
The shift back to when clearly failed to achieve consensus.
FWIW, I think then is better, because when sounds as if it should
be passed some kind of predicate or condition. It just doesn't read
very natural when taking
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 a boolean, so it
can rewrite (or contextually
On 14 November 2012 18:41, Mark S. Miller erig...@google.com wrote:
Either way, Scala's
unfortunate choice clearly violates this history in a confusing manner, so
I'd classify it as #4. Let's not repeat Scala's mistake.
Just to reiterate, it's not just Scala, but more importantly also C++,
On 14 November 2012 20:37, Tom Van Cutsem tomvc...@gmail.com wrote:
I still think futures connote strongly with blocking synchronization. If
we'd add a concept named future to JS on the grounds that the same concept
exists in Java and C++, developers will reasonably expect a blocking
On 15 November 2012 20:58, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I am talking about caller which is NOT a misfeature
Indeed, misfeature is putting it too mildly.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
On 15 November 2012 21:20, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
thanks for your contribution to this thread, appreciated. I'd like a proper
answer now if that is possible.
You already got rather strong answers from two members of TC39. It's
safe to assume that the rest feels
Consider the following code:
function f() { use strict; g() }
function g() {
var caller = Object.getOwnPropertyDescriptor(g, caller).value
}
With the current spec, this code would legally give g the strict
function f as its caller. In
On 16 November 2012 22:01, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
P.S. Alex, just to be as clear as possible, one answer I did not like that
much was that eval('no strict') nonsense ... that was not an answer 'cause
problems are the same with eval('use strict')
No, they are not.
On 19 November 2012 13:04, David Bruant bruan...@gmail.com wrote:
I wish to point out a little thought on the topic of memory management. As
far as I know, all GC algorithms I'm aware of are runtime algorithms,
meaning that the primitives of these algorithms are objects and references
between
On 16 November 2012 22:19, Jeff Walden jwalden...@mit.edu wrote:
On 11/16/2012 07:06 AM, Brendan Eich wrote:
So it seems to me premature to throw on [[GetOwnProperty]] of a strict
function's 'caller'. It would be more precise, and avoid the problem you're
hitting, to return a property
On 21 November 2012 01:06, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Tom Van Cutsem tomvc...@gmail.com wrote:
Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Tom Van Cutsem tomvc...@gmail.com wrote:
c) to ensure the stability of the result.
You can think of a + b as implementing a type
On 20 November 2012 21:30, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Nov 20, 2012 at 10:57 AM, Mark S. Miller erig...@google.com wrote:
I think adding a MultiMap API to ES7 is a good idea. Neither Map nor
MultiMap should be a subclass of the other, since neither is an LSP
subtype of
On 21 November 2012 17:55, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
I'd be more favorably inclined towards freezing than I am towards copying.
But, as you know, ES5 does not currently produce frozen objects in these
situations. I feel uncomfortable about enforcing a frozen invariant
On 21 November 2012 18:35, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
If you are writing any sort of generic algorithm that does a freeze check on
an arbitrary object you have to explicitly perform all of the internal method
calls because you don't know whether the object is a proxy
On 20 November 2012 17:26, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Yes, property descriptor records can't act like accessors. They are just
specification internal records that indicate that a set of values is being
passed around. But we can censor the value that goes into the record.
On 28 November 2012 12:50, Marius Gundersen gunder...@gmail.com wrote:
Has there been any work done on pure functions in EcmaScript? The way I
imagine it, there would be a way to indicate that a function should be pure
(by using a symbol or a new keyword, although I understand new keywords
On 28 November 2012 14:39, Marius Gundersen gunder...@gmail.com wrote:
On Wed, Nov 28, 2012 at 1:20 PM, Andreas Rossberg rossb...@google.com
wrote:
First, your definition of pure is not quite correct. Any function
that even _returns_ locally created state in some form (i.e., a new
object
On 29 November 2012 00:16, Dave Fugate dave.fug...@gmail.com wrote:
Believe you're correct on the former, but perhaps not the latter=)
E.g.:
6 /**
7* @path ch15/15.3/15.3.5/15.3.5.4/15.3.5.4_2-1gs.js
8* @description Strict mode - checking access to strict function
?
I suppose so, but was that the intention? Either way, there currently
is no test that actually tests step 2.
/Andreas
On Wed, Nov 28, 2012 at 4:43 PM, Andreas Rossberg rossb...@google.com
wrote:
On 29 November 2012 00:16, Dave Fugate dave.fug...@gmail.com wrote:
Believe you're correct
Or to null, which is exactly what the new semantics decided to do. ;)
/Andreas
On 29 November 2012 17:11, Dave Fugate dave.fug...@gmail.com wrote:
Should be: 'caller' to false :)
On Thu, Nov 29, 2012 at 9:10 AM, Dave Fugate dave.fug...@gmail.com wrote:
'caller' to true
On 4 December 2012 14:28, Claus Reinke claus.rei...@talk21.com wrote:
Could you please document the current state of concerns, pros and
cons that have emerged from your discussions so far? You don't
want to have to search for these useful clarifications when this topic
comes up again (be it in
On 5 December 2012 02:46, Brendan Eich bren...@mozilla.org wrote:
Also, good luck getting SunSpider or V8/Octane to enable use strict!
Paging Dr. Rossberg on the latter :-P.
Octane actually contains two benchmarks running in strict mode, namely
PDF/JS and GameBoy. (Unfortunately, I just
On 6 December 2012 05:05, Rick Waldron waldron.r...@gmail.com wrote:
Again, I reject the notion that someone might screw up is a valid argument
for this, or any, discussion. It's one thing to be aware of the potential
for misuse, but entirely another to succumb to fear driven design.
Fear
On 5 December 2012 19:19, Claus Reinke claus.rei...@talk21.com wrote:
their operational generativity perhaps being a mismatch with their
seemingly static meaning in certain syntactic forms,
This appears to be ungrounded. See below.
Personally, I also consider that a non-issue, but it was
On 6 December 2012 15:42, Kevin Smith khs4...@gmail.com wrote:
5) Dynamic exports via `export = ?` could make interop with existing
module systems easier. But how does that work?
Dave gave an outline. I'm liking this. What are the downsides, if any?
The downside is that it introduces a
On 6 December 2012 16:44, Domenic Denicola dome...@domenicdenicola.com wrote:
For the record, here's the idea Yehuda and I worked out:
https://gist.github.com/1ab3f0daa7b37859ce43
I would *really* appreciate if people read it (it's easy reading, I
promise!) and incorporated some of our
On 6 December 2012 17:25, Claus Reinke claus.rei...@talk21.com wrote:
I was hoping for something roughly like
let lhs = rhs; statements
// non-recursive, scope is statements
let { declarations }; statements// recursive, scope is
declarations and statements
Problem is
On 6 December 2012 17:33, Kevin Smith khs4...@gmail.com wrote:
The downside is that it introduces a severe anomaly into the module
semantics (a module which actually has no instance). I could live with
this feature if we were to find a way to explain it in terms of simple
syntactic sugar on
On 6 December 2012 17:46, Matthew Robb matthewwr...@gmail.com wrote:
What about trying it the other way, flip everything.
import foo as bar;
import foo as { baz }
Hm, I don't understand. What would that solve?
/Andreas
___
es-discuss mailing list
On 6 December 2012 22:26, Claus Reinke claus.rei...@talk21.com wrote:
I was hoping for something roughly like
let lhs = rhs; statements
// non-recursive, scope is statements
let { declarations }; statements// recursive, scope is
declarations and statements
Problem is
On 6 December 2012 18:38, Rick Waldron waldron.r...@gmail.com wrote:
I agree with other voices in this thread that in general, returning
'this' rather is an anti pattern.
The evidence I've brought to this discussion shows that the most widely used
and depended upon libraries heavily favor the
On 6 December 2012 17:54, Kevin Smith khs4...@gmail.com wrote:
Note, however, that you still assume some hack in the semantics with
the if it exists part. To avoid that, you need to divorce the import
syntax from the naming-an-external-module syntax -- which I'd actually
prefer anyway, and
On 9 December 2012 02:10, Kevin Smith khs4...@gmail.com wrote:
So if you didn't set the anonymous binding in some module x.js, what would
this do:
import x from x.js;
Would x be bound to the module instance or would we get a binding error?
Since it is just sugar, and supposed to be
On 9 December 2012 03:51, Domenic Denicola dome...@domenicdenicola.com wrote:
From: Andreas Rossberg [mailto:rossb...@google.com]
On 6 December 2012 16:44, Domenic Denicola
dome...@domenicdenicola.com wrote:
For the record, here's the idea Yehuda and I worked out:
https://gist.github.com
On 9 December 2012 15:04, Nathan Wall nathan.w...@live.com wrote:
The problem is that imports are not normal variable assignments. They
do not copy values, like normal destructuring, they are aliasing
bindings! If you were to allow arbitrary expressions and patterns,
then this would imply
On 10 December 2012 05:30, Kevin Smith khs4...@gmail.com wrote:
OK, then suppose we have these two separate forms:
import x from url; // Bind x to the anonymous export, if defined,
otherwise error
and
import module x from url; // Bind x to the module instance
In the vast majority
On 10 December 2012 21:59, Claus Reinke claus.rei...@talk21.com wrote:
Second, it doesn't eliminate the need for temporal dead zones at all.
You could well be right, and I might have been misinterpreting what
temporal dead zone (tdz) means.
For a letrec, I expect
On 14 December 2012 06:46, John-David Dalton
john.david.dal...@gmail.com wrote:
Axel Rauschmayer:
Honest question: I have yet to see boxed values in practice. Are there any
real use cases?
See Modernizr:
https://github.com/Modernizr/Modernizr/blob/master/feature-detects/video.js#L23
I think
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
exactly one way to get quick universal deployment:
rather have a structure like (modulo details of naming):
estests/
test262/
ch*/
intl402/
platforms/
/Andreas
On Fri, Dec 14, 2012 at 5:22 AM, Alex Russell slightly...@google.com
wrote:
+1. What Andreas said.
On Friday, December 14, 2012, Andreas Rossberg wrote:
On 13 December 2012
On 15 December 2012 22:52, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
So, to me, it sounds like that to continue down this path we should really
add new non-reflected properties attributes that are the real control points
for the ES semantics. Eg, we may need [[RealReadOnly]],
On 17 December 2012 13:01, Mark S. Miller erig...@google.com wrote:
On Mon, Dec 17, 2012 at 2:03 AM, Andreas Rossberg rossb...@google.com wrote:
I see the following preferable solutions to deal with DOM features violating
ES:
1. Lobby to fix the DOM and make it conform to ES instead
On 18 December 2012 22:56, Tom Van Cutsem tomvc...@gmail.com wrote:
Option B:
Address point 2) directly by changing the test that determines property
addition versus property update inside Reflect.set (i.e. the [[SetP]]
internal method of objects) so that the algorithm no longer tests whether
On 18 December 2012 20:24, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
To me, as a application programmer or even a library programmer,
enforcement of these invariants are generally unnecessary. If enforcement
impacts performance or expressibility they have a negative impact on my
ability
On 19 December 2012 16:24, Kevin Smith khs4...@gmail.com wrote:
I've worked up a concrete variation on the modules syntax:
https://gist.github.com/4337062
I believe that it presents a clean, simple model and coding experience.
Comments welcome!
Thank you! I agree with almost everything
On 19 December 2012 20:18, James Burke jrbu...@gmail.com wrote:
exports assignment is not about backcompat specifically, although it
helps. Exports assignment is more about keeping the anonymous natures
of modules preserved. In ES modules, modules do not name themselves if
it is a single
On 19 December 2012 21:29, James Burke jrbu...@gmail.com wrote:
This is illustrated by an example from Dave Herman, for a language
(sorry I do not recall which), where developers ended up using _t,
or some convention like that, to indicate a single export value that
they did not want to name.
On 19 December 2012 23:05, David Herman dher...@mozilla.com wrote:
On Dec 19, 2012, at 12:59 PM, Andreas Rossberg rossb...@google.com
wrote:
It's also worth noting that Dave's comparison is somewhat inaccurate.
The convention is used to name the _primary_ abstract type defined by a
module
On 20 December 2012 05:24, Brendan Eich bren...@mozilla.com wrote:
Domenic Denicola wrote:
IMO this is undesirable. In such a situation, modules can no longer be
abstraction boundaries. Instead you must peek inside each module and see
which form it exported itself using.
You have to know
On 20 December 2012 11:09, Tom Van Cutsem tomvc...@gmail.com wrote:
Currently, that test is performed in step 5.b. by testing whether the
current object we are visiting in the proto chain O is the Receiver
object. At first sight, this is a rather weird way of deciding between
update vs.
On 20 December 2012 14:17, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
We want to support *both* a syntax for 'import a module, and bind a
particular identifier to the single anonymous export' and a syntax for
'import a module, and bind an identifier to the module instance
object'. We
On 20 December 2012 19:39, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
More importantly, though, convention is one thing, baking it into the
language another. I've become deeply skeptical of shoe-horning orthogonal
concerns into one unified concept at the language level
On 21 December 2012 03:00, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Dec 20, 2012, at 12:07 PM, Tom Van Cutsem wrote:
I'm not sure I follow. In my understanding, the original Receiver is only
needed for traps that involve prototype-chain walking and are thus
|this|-sensitive. That
On 27 December 2012 01:50, David Herman dher...@mozilla.com wrote:
On Dec 11, 2012, at 2:45 AM, Andreas Rossberg rossb...@google.com wrote:
The question, then, boils down to what the observation should be: a
runtime error (aka temporal dead zone) or 'undefined'. Given that
choice
On 27 December 2012 06:38, David Herman dher...@mozilla.com wrote:
On Dec 24, 2012, at 1:48 AM, Anne van Kesteren ann...@annevk.nl wrote:
It seems ES6 has __proto__ which also allows modifying [[Prototype]]
so presumably this is nothing particularly bad, although it is very
ugly :-(
It
On 27 December 2012 05:53, Brendan Eich bren...@mozilla.com wrote:
I have a theory: hashes and lookup tables (arrays or vectors) have
displaced most other data structures because most of the time, for most
programs (horrible generalizations I know), you don't need ordered entries,
or other
On 27 December 2012 21:08, David Herman dher...@mozilla.com wrote:
On Dec 27, 2012, at 1:23 AM, Andreas Rossberg rossb...@google.com wrote:
var x;
if (...) { x = ... }
if (x === undefined) { ... }
If you want to use let instead, the === if-condition will throw. You
would
On 27 December 2012 21:23, David Herman dher...@mozilla.com wrote:
On Dec 27, 2012, at 1:51 AM, Andreas Rossberg rossb...@google.com wrote:
I think hoisting can mean different things, which kind of makes this
debate a bit confused.
Yep. Sometimes people mean the scope extends to a region
On 27 December 2012 23:38, Andreas Rossberg rossb...@google.com wrote:
I don't feel qualified to talk for Scheme, but all Ocaml I've ever
seen (SML uses more verbose 'let' syntax anyway) formatted the above as
let sq = x * x in
print (sq: ^ toString sq ^ \n);
let y = sq / 2
On 27 December 2012 18:25, Brendan Eich bren...@mozilla.com wrote:
That is, if having it at all, I'd still think it much wiser to ban it to
some Appendix.
What earthly good would that do?
Marketing and psychology (as I said, being important). It would send a
clear message that it is just
On 28 December 2012 05:38, Brendan Eich bren...@mozilla.com wrote:
No point whinging about it in appendices that either no one reads, or else
people read and think less of the spec on that account.
The fewer read about it the better, no? :)
Why would people think less about the spec?
I
On 28 December 2012 07:10, David Herman dher...@mozilla.com wrote:
On Dec 27, 2012, at 2:13 PM, Andreas Rossberg rossb...@google.com wrote:
It's true that with TDZ, there is a difference between the two forms
above, but that is irrelevant, because that difference can only be observed
On 28 December 2012 11:22, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
As for TDZ precedent, ES6 will have plenty of precedent of other
lexical declaration forms that uniformly have TDZ and would not allow an
example like the above.
Can these plenty be enumerated
On 28 December 2012 11:51, David Bruant bruan...@gmail.com wrote:
Le 28/12/2012 11:20, Brendan Eich a écrit :
David Bruant wrote:
What about a specific section of the spec called de facto standards?
It would indicate that it's part of the standard, but is a scar from
history rather than a
On 28 December 2012 13:34, Herby Vojčík he...@mailbox.sk wrote:
Andreas Rossberg wrote:
That's a good point, actually. I, for one, do not understand the
criteria by which we chose to include __proto__ but not __defineGetter__
and friends.
__defineGetter__ and friends have sane
On 28 December 2012 16:20, Domenic Denicola dome...@domenicdenicola.comwrote:
Now that I have fully digested Andreas's points from the earlier thread
on modules [1], I am a bit concerned about the implications of `import`
introducing aliasing bindings. To recap, the situation is:
module foo
On 28 December 2012 17:54, David Herman dher...@mozilla.com wrote:
Another one is that I've been thinking we should add getter/setter exports
to make it possible to create lazily initialized exports:
We haven't had the opportunity to discuss that one, but now that you
mention it, I should say
On 28 December 2012 19:55, Mark S. Miller erig...@google.com wrote:
That is exactly the issue. As long as it was not expected in IE, it
could not be assumed by the cross-browser web. However, mobile changed
MS's tradeoffs. Mobile is currently a separate enough ecosystem, with
IE a
On 28 December 2012 20:30, David Herman dher...@mozilla.com wrote:
Andreas, can you explain why you dismiss TDZ-RBA-UNDEF as a viable option?
The bug that motivates all the arguments you've made is
read-before-initialization, not write-before-initialization.
I agree that that would be a
On 28 December 2012 20:53, David Herman dher...@mozilla.com wrote:
On Dec 28, 2012, at 11:47 AM, Andreas Rossberg rossb...@google.com wrote:
That seems clean, useful, consistent, and fairly easy to understand.
Introducing extra rules for 'let'? Not so much.
But TDZ does introduce extra rules
I haven't replied to this thread yet, because I feel that I already
made all the same arguments repeatedly to no avail. ;) However, let
me reiterate one particular observation, which is that IMHO much of
the discussion (and decision making) around 1JS, modes, and opt-ins is
just mistargeted.
On 29 December 2012 14:51, Axel Rauschmayer a...@rauschma.de wrote:
I’m sympathetic to both sides of this argument. How would you handle things?
Ideally? Backing out of the whole 1JS marketing maneuver? In the long
run, I see it as more harmful than helpful, as it inevitably leads to
complexity
On 29 December 2012 22:06, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
ES6+ will stay much longer (at least that's what we are working for).
Consequently, what should take precedence are the expectations and
needs of _future_ users of ES. Those who will come to ES6+ without
On 29 December 2012 22:11, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
On 29 December 2012 14:51, Axel Rauschmayera...@rauschma.de wrote:
I’m sympathetic to both sides of this argument. How would you handle
things?
Ideally? Backing out of the whole 1JS marketing
On 30 December 2012 02:31, Mark S. Miller erig...@google.com wrote:
If duplicate formals are the only such case, then I agree that the
fear of micro-mode is a non-issue. Do we have an accurate record of
the scoping of default value expressions? How about the interaction of
head scope and top
On 30 December 2012 11:58, Brendan Eich bren...@mozilla.com wrote:
Two separate things:
1. All new syntax with code bodies makes strict-by-fiat code bodies.
2. New parameter forms restrict duplicate parameters.
Neither entails various features locally chang[ing] the semantics of
unrelated
On 30 December 2012 12:50, Axel Rauschmayer a...@rauschma.de wrote:
It would actually be nice to have that as a feature: If the variable name is
`_` then it can be used multiple times. It’s a nice, self-descriptive way of
saying that you don’t care about a parameter value.
That underscore
On Jan 2, 2013, at 7:58 PM, Brendan Eich wrote:
I think we can do this now. Allen should weigh in. Hope to hear from Andreas
R. soon too!
Apologies for the long thread, and thanks to Herby for interaction that
clarified many things. Perhaps I should resummarize:
The best new-new plan to
On 1 January 2013 07:09, Mark Miller erig...@gmail.com wrote:
On Mon, Dec 31, 2012 at 9:12 PM, Brendan Eich bren...@mozilla.com wrote:
Mark S. Miller wrote:
I'm pretty happy with Kevin's compromise. Here it is again:
(1) No opt-in required for new syntax, except:
(2) No breaking changes to
a
double use as implicit opt-in/pragma has merit.
How does making certain constructs opt in implicitly resolve any of
the ambiguities you mentioned?
/Andreas
On Wednesday, January 16, 2013, Andreas Rossberg wrote:
On 1 January 2013 07:09, Mark Miller erig...@gmail.com wrote:
On Mon, Dec 31
On 15 January 2013 17:16, Kevin Smith khs4...@gmail.com wrote:
It's really none of your business when you try to freeze my object whether
any of
(a) pre-existing private-symbol-named properties remain writable;
(b) weakmap-encoded private state remains writable;
(c) objects-as-closures
On 8 January 2013 22:33, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Jan 8, 2013 at 1:30 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
so you are saying that Object.observe() does not suffer these problems ? Or
is just much simpler than Proxies ? ( yeah, I know, I guess both
On 17 January 2013 18:00, Mark S. Miller erig...@google.com wrote:
I still have this position on classes. But I no longer buy that
pessimistic conclusion about WeakMaps. Consider how WeakMaps would be
used by the expansion of classes-with-private. Just 'cause it's on the
top of my head, below
On 17 January 2013 21:08, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
Actually, I don't see why this should have a measurable impact on
performance in practice. The generic case is dog-slow for JavaScript
anyway, what matters is how easy it is to specialise for the types
Amen.
/Andreas
On 21 Jan 2013 17:23, Tom Van Cutsem tomvc...@gmail.com wrote:
2013/1/20 Allen Wirfs-Brock al...@wirfs-brock.com
I don't have a problem at all with making the proxy story more
complicated. Proxys are an expert feature designed for some specific use
cases. they are probably
[Meta]
David, I would appreciate if you stopped breaking discussion threads
all the time. There are now about half a dozen threads related to
WeakMap clear, which clutters the discussion view and makes it hard to
properly follow the discussion with delay.
Thanks,
/Andreas
On 23 January 2013
On 28 January 2013 19:45, Tom Van Cutsem tomvc...@gmail.com wrote:
I just wrote up a strawman on the wiki to summarize the recent debates about
the interaction between proxies and private symbols:
http://wiki.ecmascript.org/doku.php?id=strawman:proxy_symbol_decoupled
The page actually lists
On 29 January 2013 21:14, Tom Van Cutsem tomvc...@gmail.com wrote:
2013/1/29 Brandon Benvie bran...@brandonbenvie.com
Proxies are the thing that ultimately complicates the object model and
these are fallout from it, but most of us agree that Proxies are worth it.
I think this is a strange
On 30 January 2013 18:00, Andrea Giammarchi andrea.giammar...@gmail.com wrote:
let me rephrase ...
putting `with(this){` before any build process/inlined library and `}` at
the end of all concatenated files **nothing** is strict anymore ^_^
function isStrict() {use strict;
return this;
}
On 30 January 2013 17:19, Brandon Benvie bran...@brandonbenvie.com wrote:
Correction, the use strict directive needs to appear as the first statement
(ExpressionStatement) that's not an EmptyStatement and not a
FunctionDeclaration. Anything else will cause the directive to be ignored.
_Any_
I wrote up the semantics of refutable destructuring as discussed in
yesterday's meeting:
http://wiki.ecmascript.org/doku.php?id=harmony:refutable_matching
In particular, this defines the meaning of the ?-operator in a fairly
straightforward manner.
The page also describes how the proposed
On 1 February 2013 10:56, Axel Rauschmayer a...@rauschma.de wrote:
Beautiful.
What do question marks in value (as opposed to key) positions mean?
Example: { a: x? }
Not much: a plain identifier 'x' is always matches anyway, i.e. is
already irrefutable, so wrapping a '?' around it does not
301 - 400 of 778 matches
Mail list logo
