Tab Atkins Jr. mailto:jackalm...@gmail.com
January 22, 2012 11:44 PM
Allow me to be clearer.
Given foo.bar = new Name();, is b...@foo.bar equivalent to
baz[foo.bar] or baz[foo].bar?
There's no requirement that @ be lower precedence than a later dot. The
abstract syntax is the same as (if
On Jan 22, 2012, at 10:29 PM, Brendan Eich wrote:
1) should .@ member access and @ object literal property definitions permit
he property key to be any toString-able value and not just private name
values? The current plan of record does not require a private name value in
the analogous
On Fri, 2012-01-20 at 19:19 +0100, Andreas Rossberg wrote:
How is
function(x) { let x }
any different in this respect from
{ let x { let x } }
In the former, there is no part of the body in which the parameter is
visible (modulo arguments, of course). I can see how that might be
It seems like an unfortunate inconvenience to require any code refactoring
and lose the shorthand @ this-access if you just want to make a private
property on an object be public. Instead of just restricting the token to
the right of a @ or .@ construct be a private name, perhaps it would
Axel Rauschmayer mailto:a...@rauschma.de
January 23, 2012 1:21 AM
I wouldn’t mix public and private, but it would be nice to have
symmetry – only having a `this` shortcut for private names feels odd.
How about the following?
function Point(everyone, secret) {
this.everyone = everyone;
function Point(everyone, secret) {
.everyone = everyone;
You're requiring manual semicolon insertion before lines like this.
Consciously?
Sight. Right. Not a good idea, then.
An important consideration is that eliminating `this` will increase the
grawlix-factor of JavaScript (I always
Just to confirm: you are not alone. I always thought that allowing to imply
local this (‘this.’) was a bad idea (C#). Seriously, this is not 5 chars
that’ll hurt but it could make IDE work a lot easier, and it make code reuse
more efficient (if you need to copy/paste some code, if you stay in
Note: JavaScript will never go the Java or C# route of including properties in
local scope (which would be just like `with`), there will just be a shortcut
for `this` (so IDEs won’t have a problem).
But I agree with your other points: my taste is such that 5 chars are not worth
the increase in
On 23 January 2012 01:31, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
2) elimination of arbitrary expression as direct keys in object literal
property definitions:
The current computed property keys proposals allows things like:
for (var n=0;n10;) {
a.push( {
[prop+n]: n++
On 22 January 2012 18:52, David Bruant bruan...@gmail.com wrote:
SpiderMonkey implementation landed today. I was looking over the commit
[1] and had a question.
There is a test:
assertEq(Object.prototype.toString.call(new Map), [object Map]);
FWIW, V8 behaves the same. It's not in the spec
On 20 January 2012 20:51, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
This is a recurring discussion. The discussion always seems to resolve
(perhaps with some unhappy acquiesce) that we want to follow the C++/Java/C#
(and other similar language) precedent adjusted to deal with legacy var
Allen Wirfs-Brock wrote:
The following is just speculation...One possible such bottleneck
might be whole object allocation. A JS clone function probably would
have to allocate an empty object and then dynamically populate it by
adding properties one at a time. A native implementation is more
On Jan 23, 2012, at 12:21 , Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
I plan on proposing at the next TC39 meeting that we support .@ member
accesses and that we replace the use of [expr ] to define private named
properties in object literals (
On 21 January 2012 20:36, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Jan 21, 2012, at 12:25 AM, Andreas Rossberg wrote:
On 21 January 2012 01:23, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Temporal dead-zone initialization tracking requires extra state and checking
(except for the
On Mon, Jan 23, 2012 at 5:19 AM, Andreas Rossberg rossb...@google.com wrote:
On 22 January 2012 18:52, David Bruant bruan...@gmail.com wrote:
SpiderMonkey implementation landed today. I was looking over the commit
[1] and had a question.
There is a test:
On 22 January 2012 23:46, Gavin Barraclough barraclo...@apple.com wrote:
On Jan 20, 2012, at 4:23 PM, Allen Wirfs-Brock wrote:
I'm not yet convinced that you need to publicly expose such global object
properties accessor properties. I think it is possible to hide the
mechanisms.
I'm
On 23 January 2012 14:54, Andreas Rossberg rossb...@google.com wrote:
One thing I noticed with your comments is that they consider the
global scope almost exclusively from the object perspective, i.e., as
special syntax for putting properties on the global object. But first
and foremost, it is
On Mon, Jan 23, 2012 at 8:53 AM, Sam Tobin-Hochstadt sa...@ccs.neu.eduwrote:
On Mon, Jan 23, 2012 at 5:19 AM, Andreas Rossberg rossb...@google.com
wrote:
On 22 January 2012 18:52, David Bruant bruan...@gmail.com wrote:
SpiderMonkey implementation landed today. I was looking over the
On Mon, Jan 23, 2012 at 8:54 AM, Andreas Rossberg rossb...@google.com wrote:
One thing I noticed with your comments is that they consider the
global scope almost exclusively from the object perspective, i.e., as
special syntax for putting properties on the global object. But first
and
On Mon, Jan 23, 2012 at 9:23 AM, Rick Waldron waldron.r...@gmail.com wrote:
On Mon, Jan 23, 2012 at 8:53 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
wrote:
On Mon, Jan 23, 2012 at 5:19 AM, Andreas Rossberg rossb...@google.com
wrote:
On 22 January 2012 18:52, David Bruant bruan...@gmail.com
On 23 January 2012 15:58, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
Putting properties on the global object is an important use case.
We don't want people to need to reach for |var| when they want to do
this (see t-shirt discussion). Therefore, we may well need to
compromise some cleanups
Herby Vojčík mailto:he...@mailbox.sk
January 23, 2012 3:21 AM
It can be solved this way:
module {
private foo, bar;
export function factory1 (args) { ... }
export function factory2 (args) { ... }
but then foo and bar are known to the rest of the module. It was not
the premise.
David Bruant mailto:bruan...@gmail.com
January 22, 2012 12:54 PM
I'm not sure to understand what you're calling /the/ key.
WeakMap.prototype, being itself a weakmap, does provide a covert
channel (since everyone has access to the same primordial objects
identities). Of course, it can be
Andreas Rossberg mailto:rossb...@google.com
January 23, 2012 5:54 AM
On 22 January 2012 23:46, Gavin Barracloughbarraclo...@apple.com wrote:
On Jan 20, 2012, at 4:23 PM, Allen Wirfs-Brock wrote:
I'm not yet convinced that you need to publicly expose such global object
properties accessor
Allen Wirfs-Brock mailto:al...@wirfs-brock.com
January 23, 2012 8:43 AM
On Jan 22, 2012, at 7:36 PM, Tab Atkins Jr. wrote:
For example, from my post:
myCoolObject.prototype[Iterator.getIterator] = function(){...}
Using @ for access, would
myCoolObject.prototype.@Iterator.getIterator =
Hello,
for those who cannot edit (or don't want to pollute)
wiki.ecmascript.org, I installed dokuwiki at
http://dw.herby.sk/doku.php?id=es.next:start where you can login with
strawman:harmony and play with variants of wiki.ecmascript.org's
strawman or proposal pages. Ask me personally if you
for what it's worth it ...
Object.defineProperty(Object.prototype, new, {value: function
(descriptor) {
return Object.create(typeof this == function ?
this.prototype :
this,
descriptor || {}
);
}});
Map.new() and Math.new() should both work
my 2 cents
On Mon, Jan 23, 2012 at
On 23 January 2012 18:39, Brendan Eich bren...@mozilla.org wrote:
Andreas Rossberg mailto:rossb...@google.com
In other words, the current behaviour breaks both scoping and objects
semantics.
Non-strict or really pre-strict implementations broke scoping semantics --
no temporal dead zone.
Github gists seem better for this and they've been used recently. See e.g.
https://gist.github.com/1329619
https://gist.github.com/1332193
etc.
/be
Herby Vojčík mailto:he...@mailbox.sk
January 22, 2012 9:49 AM
Hello,
for those who cannot edit (or don't want to pollute)
wiki.ecmascript.org,
We're not going to force everyone to use Map.new, so while this might be
nice new API, it doesn't solve the problem of the prototype channel.
/be
Andrea Giammarchi mailto:andrea.giammar...@gmail.com
January 23, 2012 10:13 AM
for what it's worth it ...
Object.defineProperty(Object.prototype,
Andreas Rossberg mailto:rossb...@google.com
January 23, 2012 10:15 AM
On 23 January 2012 18:39, Brendan Eichbren...@mozilla.org wrote:
Andreas Rossbergmailto:rossb...@google.com
In other words, the current behaviour breaks both scoping and objects
semantics.
Non-strict or really pre-strict
Below...Brendan Eich bren...@mozilla.org wrote: Allen Wirfs-Brock
mailto:al...@wirfs-brock.com
January 23, 2012 8:43 AM
On Jan 22, 2012, at 7:36 PM, Tab Atkins Jr. wrote:
?..
const getIterator = Iterator.getIterator;
myCoolObject.prototype.@getIterator = function() {...}
Why wouldn't
Allen Wirfs-Brock mailto:al...@wirfs-brock.com
January 23, 2012 11:01 AM
Below...
Brendan Eich bren...@mozilla.org wrote:
Allen Wirfs-Brock mailto:al...@wirfs-brock.com
January 23, 2012 8:43 AM
On Jan 22, 2012, at 7:36 PM, Tab Atkins Jr. wrote:
?..
const getIterator = Iterator.getIterator;
Brendan Eich mailto:bren...@mozilla.org
January 23, 2012 11:08 AM
We run into this kind of trade-off all the time, but the fact is that
right now, dot and brackets are equivalent for properties named by
strings that match the IdentifierName lexical production. This isn't
the case for private
Brendan Eich-2 wrote:
Herby Vojčík mailto:he...@mailbox.sk
January 23, 2012 3:21 AM
It can be solved this way:
module {
private foo, bar;
export function factory1 (args) { ... }
export function factory2 (args) { ... }
but then foo and bar are known to the rest of the
Allen Wirfs-Brock wrote:
Below...
Brendan Eich bren...@mozilla.org wrote:
Allen Wirfs-Brock mailto:al...@wirfs-brock.com
January 23, 2012 8:43 AM
On Jan 22, 2012, at 7:36 PM, Tab Atkins Jr. wrote:
?..
const getIterator = Iterator.getIterator;
myCoolObject.prototype.@getIterator =
Herby Vojčík mailto:he...@mailbox.sk
January 23, 2012 11:51 AM
Brendan Eich-2 wrote:
Herby Vojčíkmailto:he...@mailbox.sk
January 23, 2012 3:21 AM
It can be solved this way:
module {
private foo, bar;
export function factory1 (args) { ... }
export function factory2 (args) {
Le 23/01/2012 17:25, Brendan Eich a écrit :
David Bruant mailto:bruan...@gmail.com
January 22, 2012 12:54 PM
I'm not sure to understand what you're calling /the/ key.
WeakMap.prototype, being itself a weakmap, does provide a covert
channel (since everyone has access to the same primordial
Losing generic [] as a way to access all native properties of the object is
big price.
I wonder if it really is such a big price: isn’t [] mainly used for objects as
maps from strings to values? Then you should use something else in ES6, anyway
(SimpleMap, possibly dict, possibly other map
David Bruant mailto:bruan...@gmail.com
January 23, 2012 12:37 PM
Can you elaborate on this last point? Do you mean a run-time way?
No, spec way.
For the record, this rule (no irrevocable access by default to objects
with mutable state) was applied in the design of Joe-E [1], a subset
of Java
On Jan 23, 2012, at 12:27 PM, Brendan Eich wrote:
No, the private binding form that is desugared from
private foo;
to
const foo = Name.create(foo);
or better (with hygiene to use the right Name, etc.) is lexical in its
binding structure.
Is the intention here that the private
Brendan Eich wrote:
Herby Vojčík mailto:he...@mailbox.sk
January 23, 2012 11:51 AM
Brendan Eich-2 wrote:
Herby Vojčíkmailto:he...@mailbox.sk
January 23, 2012 3:21 AM
module {
private foo, bar;
export function factory1 (args) { ... }
export function factory2 (args) { ... }
but then foo and
Gavin Barraclough mailto:barraclo...@apple.com
January 23, 2012 12:54 PM
On Jan 23, 2012, at 12:27 PM, Brendan Eich wrote:
Is the intention here that the private name object would be in scope,
and accessible to the user? – if so, this does seem useful, but using
the plain name of the property
Axel Rauschmayer wrote:
Losing generic [] as a way to access all native properties of the
object is big price.
I wonder if it really is such a big price: isn’t [] mainly used for
objects as maps from strings to values? Then you should use something
else in ES6, anyway (SimpleMap, possibly
On Jan 23, 2012, at 1:11 PM, Brendan Eich wrote:
Then I think we considered a proposal where private x; bound in a separate
lexical chain but that chain was searched *only* on right of @. That proposal
seemed not to have the readability drawback. It also solves the problem you
show above?
Just saw this tweeted:
http://slexaxton.github.com/Jed/
Wondered if anyone has any reactions. We have a Globalization API
rushing to standardization while libraries to do some of what it does
exist on github.com. It seems to me we ought to look at the latter while
finalizing the former -- if
Gavin Barraclough mailto:barraclo...@apple.com
January 23, 2012 1:22 PM
On Jan 23, 2012, at 1:11 PM, Brendan Eich wrote:
Ah, that's the detail that I'd missed! - if private names will be
ignored if they are not to the right of @, then presumably my example
*would* result in at least a
On Mon, Jan 23, 2012 at 5:37 AM, Herby Vojčík he...@mailbox.sk wrote:
Allen Wirfs-Brock wrote:
The following is just speculation...One possible such bottleneck
might be whole object allocation. A JS clone function probably would
have to allocate an empty object and then dynamically populate
He is unfortunately using term internationalization for localization.
This library only lets you handle resource loading - i.e. translated
messages.
Our library deals with proper formatting and sorting (and possibly many
more in the future). The actual sorting (collation) is the hard part where
I think I'm largely in agreement with what you were saying below, but I do have
some additional thoughts I added below...
On Jan 23, 2012, at 11:28 AM, Brendan Eich wrote:
Brendan Eich mailto:bren...@mozilla.org
January 23, 2012 11:08 AM
We run into this kind of trade-off all the time, but
On Jan 23, 2012, at 1:14 PM, Herby Vojčík wrote:
Axel Rauschmayer wrote:
Losing generic [] as a way to access all native properties of the
object is big price.
I wonder if it really is such a big price: isn’t [] mainly used for
objects as maps from strings to values? Then you should use
On Jan 23, 2012, at 4:58 PM, Russell Leggett russell.legg...@gmail.com wrote:
On Mon, Jan 23, 2012 at 5:37 AM, Herby Vojčík he...@mailbox.sk wrote:
Allen Wirfs-Brock wrote:
The following is just speculation...One possible such bottleneck
might be whole object allocation. A JS clone function
Well, Jed does a little more than you give it credit for, but there's still no
real overlap.
Jed provides the following functionality:
- an incomplete implementation of resource loading (no language negotiation, no
I/O, only dictionary lookup),
- an incomplete implementation of plural handling
Hi all,
I'm the author of said Jed library. I'd be happy to update the info on
the Jed site with the correct terminology, but I was wondering why the term
internationalization is incorrect? It's an implementation of the Gettext
spec (with a few wrappers) which GNU defines as an
A few questions inline. I'd love to continue to improve Jed to the point
where it can handle the problems that you've outlined.
On Mon, Jan 23, 2012 at 6:57 PM, Norbert Lindenberg
ecmascr...@norbertlindenberg.com wrote:
Well, Jed does a little more than you give it credit for, but there's
As part of the HTML5 specification, there is the structured clone
algorithmhttp://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data
Which is also incapable of copying a function.
True, but the original suggestion was limited only to the json subset.
Hi Alex,
Comments inline.
Cheers,
Norbert
On Jan 23, 2012, at 17:14 , Alex Sexton wrote:
A few questions inline. I'd love to continue to improve Jed to the point
where it can handle the problems that you've outlined.
On Mon, Jan 23, 2012 at 6:57 PM, Norbert Lindenberg
I'd agree that Jed is an internationalization library. Code that enables
localization to me is internationalization. But the
internationalization/localization/globalization community speaks a number of
different dialects...
The current spec of the proposed ECMAScript Globalization API is at:
Also, the square bracket preference also currently shows up in the object
literal computed property key proposal so we already have
obj[privateNameValue] pattern manifesting itself as new ES6 syntax.
Would [] in object literals still make sense if [] was to become a data-only
operator?
--
59 matches
Mail list logo
