On Sat, Jan 28, 2012 at 1:10 AM, Brendan Eich bren...@mozilla.org wrote:
Tom Van Cutsem mailto:tomvc...@gmail.com
January 27, 2012 10:53 AM
Off-topic: What is the recommended style for naming modules?
Capitalized and camel-cased? It’s nothing I couldn’t get used to,
but it seems
2012/1/23 Herby Vojčík he...@mailbox.sk
But it gets harder with getters and setters... maybe if there was an API
for simulating proper legacy foo[bar] and foo[bar]=baz, (Object.get,
Object.set?) generic [] could be dropped without much of a loss.
We'll have Reflect.get and Reflect.set, see
Off-topic: What is the recommended style for naming modules? Capitalized and
camel-cased? It’s nothing I couldn’t get used to, but it seems like the naming
precedent would be JavaScript packages. Or is Reflect capitalized, because it
is a built-in module?
I love how this module is a new home
2012/1/27 Axel Rauschmayer a...@rauschma.de
Off-topic: What is the recommended style for naming modules? Capitalized
and camel-cased? It’s nothing I couldn’t get used to, but it seems like the
naming precedent would be JavaScript packages. Or is Reflect capitalized,
because it is a built-in
Tom Van Cutsem mailto:tomvc...@gmail.com
January 27, 2012 10:53 AM
Off-topic: What is the recommended style for naming modules?
Capitalized and camel-cased? It’s nothing I couldn’t get used to,
but it seems like the naming precedent would be JavaScript
packages. Or is Reflect
1. List (or Sequence or something else): same interface as Array (hence
array-like). No holes, indices are non-negative integers, etc.
2. Map (possibly the SimpleMap that has already been specified).
One reason I introduced this the OMR strawman when I did is because we are
already
(resend to list; forgot)
Sorry for late answer, but I lost mails from Monday 4:30-17:30 CET, so I
waited for them to appear in .gz archive to download and import them to
mu inbox again.
Answers below.
Brendan Eich wrote:
Herby Voj??kmailto:herby at mailbox.sk
January 22, 2012 12:34 PM
Allen Wirfs-Brock wrote:
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.
... For the few remaining cases, Object.getProperty() (or
something similar) should do just fine.
Hm.
On Jan 23, 2012, at 7:43 PM, Axel Rauschmayer wrote:
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
Reiterating my support for the reformed object model (ROM): I love how the ROM
will finally end the clashes between application data (array elements, entries
in objects-as-maps) and program definition (methods, non-method properties).
It’s a nice clean-up, with a clear migration strategy.
Axel Rauschmayer mailto:a...@rauschma.de
January 24, 2012 11:06 AM
Reiterating my support for the reformed object model (ROM): I love how
the ROM will finally end the clashes between application data (array
elements, entries in objects-as-maps) and program definition (methods,
non-method
Reiterating my support for the reformed object model (ROM): I love how the
ROM will finally end the clashes between application data (array elements,
entries in objects-as-maps) and program definition (methods, non-method
properties). It’s a nice clean-up, with a clear migration strategy.
On Jan 24, 2012, at 12:35 PM, Axel Rauschmayer wrote:
Reiterating my support for the reformed object model (ROM): I love how the
ROM will finally end the clashes between application data (array elements,
entries in objects-as-maps) and program definition (methods, non-method
properties).
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
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
block-local private names,plays nicely with
@foo syntax
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
Rauschmayer
Sent: Monday, January 23, 2012 10:26 AM
To: Brendan Eich
Cc: ECMAScript discussion
Subject: Re: shortcuts for defining block-local private names,plays nicely
with @foo syntax
function Point(everyone, secret) {
.everyone = everyone;
You're requiring manual semicolon insertion
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 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 (
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.
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 =
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) {
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
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?
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
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
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?
--
Brendan Eich wrote:
Herby Vojčík mailto:he...@mailbox.sk
January 21, 2012 2:21 PM
Oh. I favor 1. Inspired by latest notes and for(let...) I would see
{
private foo;
...
}
desugared to
{
let foo = _the_real_foo;
Er, const, I hope -- not let. Right?
Of course. My mistake.
/be
Herby
Brendan Eich wrote:
And _the_real_foo should be expanded:
{
private foo;
...
}
desugars to
{
const foo = Name.create(foo);
...
}
with Name.create imported appropriately.
No, I though more in lines of:
// singleton code, in module level / program level
// generated from all private
I suspect your very complicated translation with __prvTable__ etc. is
intended to hoist private somehow, once per declaration in source rather
than once per evaluation of declaration. That's too restrictive, since
private declarations can be placed in outer blocks or closures for
singleton
Brendan Eich wrote:
I suspect your very complicated translation with __prvTable__ etc. is
intended to hoist private somehow, once per declaration in source rather
than once per evaluation of declaration. That's too restrictive, since
Exactly. By design.
private declarations can be placed in
On Jan 21, 2012, at 12:07 PM, Brendan Eich wrote:
This was already proposed. See the whole strawman, but in particular these
sections:
http://wiki.ecmascript.org/doku.php?id=strawman:private_names#the_private_declaration
On Sun, Jan 22, 2012 at 4:31 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
I personally have come to the conclusions that
obj.@foo
would be a better than
obj[foo]
for accessing a property of obj that is keyed by the private name that is
the value of the foo binding.
My
Allen Wirfs-Brock mailto:al...@wirfs-brock.com
January 22, 2012 4:31 PM
I personally have come to the conclusions that
obj.@foo
would be a better than
obj[foo]
for accessing a property of obj that is keyed by the private name that
is the value of the foo binding.
My impression, is
Tab Atkins Jr. mailto:jackalm...@gmail.com
January 22, 2012 7:36 PM
myCoolObject.prototype[Iterator.getIterator] = function(){...}
Using @ for access, would
myCoolObject.prototype.@Iterator.getIterator = function(){...} work,
or would that attempt to retrieve a property using Iterator as a
On Sun, Jan 22, 2012 at 11:25 PM, Brendan Eich bren...@mozilla.org wrote:
Tab Atkins Jr. mailto:jackalm...@gmail.com
January 22, 2012 7:36 PM
myCoolObject.prototype[Iterator.getIterator] = function(){...}
Using @ for access, would myCoolObject.prototype.@Iterator.getIterator =
Hello,
since @-prefixed syntax to access private-named properties seems to win
in the private grounds (and it is good thing), I'd like kill two birds
with one stone:
- private keyword seemed to lose its role
- to access property via @foo, I must 'let foo = Name.create()' first
So let us
This was already proposed. See the whole strawman, but in particular
these sections:
http://wiki.ecmascript.org/doku.php?id=strawman:private_names#the_private_declaration
http://wiki.ecmascript.org/doku.php?id=strawman:private_names#private_declaration_scoping
Brendan Eich wrote:
This was already proposed. See the whole strawman, but in particular
these sections:
http://wiki.ecmascript.org/doku.php?id=strawman:private_names#the_private_declaration
http://wiki.ecmascript.org/doku.php?id=strawman:private_names#private_declaration_scoping
Herby Vojčík mailto:he...@mailbox.sk
January 21, 2012 1:33 PM
Brendan Eich wrote:
This was already proposed. See the whole strawman, but in particular
these sections:
http://wiki.ecmascript.org/doku.php?id=strawman:private_names#the_private_declaration
Brendan Eich wrote:
Herby Vojčík mailto:he...@mailbox.sk
January 21, 2012 1:33 PM
Brendan Eich wrote:
http://wiki.ecmascript.org/doku.php?id=strawman:private_names#private_declarations_exist_in_a_separate_name_space_parallel_to_the_variable_binding_environment
The last really was too much for
Herby Vojčík mailto:he...@mailbox.sk
January 21, 2012 1:56 PM
Brendan Eich wrote:
Herby Vojčík mailto:he...@mailbox.sk
January 21, 2012 1:33 PM
Brendan Eich wrote:
Brendan Eich wrote:
Herby Vojčík mailto:he...@mailbox.sk
January 21, 2012 1:56 PM
Brendan Eich wrote:
private foo;
@foo = bar; // this-relative private foo
return @foo === other.@foo;
return {@foo: bar};
This helps a lot, but there still _is_ an
identifier foo having that private name in
Brendan Eich mailto:bren...@mozilla.org
January 21, 2012 4:39 PM
Er, const, I hope -- not let. Right?
And _the_real_foo should be expanded:
{
private foo;
...
}
desugars to
{
const foo = Name.create(foo);
...
}
with Name.create imported appropriately.
/be
57 matches
Mail list logo
