Two kinds of [] (was: Re: shortcuts for defining block-local private names, plays nicely with @foo syntax)
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 implementations). For the few remaining cases, Object.getProperty() (or something similar) should do just fine.
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 dict, possibly other map implementations). For the few remaining cases, Object.getProperty() (or something similar) should do just fine.
Hm. Well, maybe you are right.
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.
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 something else in ES6, anyway (SimpleMap, possibly dict, possibly other map implementations). For the few remaining cases, Object.getProperty() (or something similar) should do just fine.
Hm. Well, maybe you are right.
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.
It sounds like you need to read strawman:object_model_reformation
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. Well, maybe you are right.
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.
It sounds like you need to read strawman:object_model_reformation
Allen
Sorry. I have read it, but not studied in detail. I remembered the main idea only (the [] overloading).
"A side note on reflective property access" does the trick.
Yes.
2012/1/23 Herby Vojčík <herby at 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 < harmony:reflect_api>. (these are the methods referred to as Object.getProperty and Object.setProperty that Allen referred to on the object model reformation wiki page)
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 for many Object.* methods. Also looking forward to @math etc.: harmony:modules_standard
2012/1/27 Axel Rauschmayer <axel at 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 module?
I have been using @reflect as the name of the module, and Reflect as the name of the module instance object, as in:
module Reflect from "@reflect";
Not sure if that is still the correct module syntax (and naming convention).
Tom Van Cutsem <mailto:tomvc.be at 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 capitalized, because it is a built-in module?I have been using @reflect as the name of the module, and Reflect as the name of the module instance object, as in:
module Reflect from "@reflect";
I believe that the latest (not yet in wiki) syntax uses 'at' not 'from' for the out-of-line module body case:
module M { ... } module N at "U"; import P from M; import P from "U";
P is a pattern, in general. It could be * or an identifier if not a full destructuring pattern.
On Sat, Jan 28, 2012 at 1:10 AM, Brendan Eich <brendan at mozilla.org> wrote:
Tom Van Cutsem <mailto:tomvc.be at 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 capitalized, because it is a built-in module?
I have been using @reflect as the name of the module, and Reflect as the name of the module instance object, as in:
module Reflect from "@reflect";
I believe that the latest (not yet in wiki) syntax uses 'at' not 'from' for the out-of-line module body case:
module M { ... } module N at "U"; import P from M; import P from "U";
P is a pattern, in general. It could be * or an identifier if not a full destructuring pattern.
Related: this syntax doesn't prevent the user from naming its variable "at", does it?
Thaddee Tyl wrote:
Related: this syntax doesn't prevent the user from naming its variable "at", does it?
Not at all (heh). Contextual keyword is contextual (and not optional, so it will always be linking a module name to an MRL).
Allen Wirfs-Brock wrote:
Losing generic [] as a way to access all "native" properties of the object is big price. What about half-way: modify object reformation to have "native []" and "logical []" in parallel.
You can use x.foo x["foo"] x.["foo"] syntaxes (and x. at priv, too), and if you define the latter as "native property access", for the time being equivalent to [], but later [] can be redefined (or vice versa, but it seems .[] is more akin to . and .@ and [] seems better for "logical" element access), you've got the collection [] but don't lose the object-structural [].
Allen Wirfs-Brock wrote: > > Below... > Brendan Eich <brendan at mozilla.org> wrote: > > Allen Wirfs-Brock <mailto:allen at 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. at getIterator = function() {...} > > Why wouldn't myCoolObject.prototype[iterator.getIterator] work? > > /be > > It would, for now. But, I think you gave the reason for avoiding this > pattern in another reply. If we ever want to adopt my Reformed Object > Model proposal then we should avoid using [ ] for private name property > access. lt would actually still work fine for objects with default [ ] > behavior but not for collection objects that redefine [ ] access. Losing generic [] as a way to access all "native" properties of the object is big price. What about half-way: modify object reformation to have "native []" and "logical []" in parallel. You can use x.foo x["foo"] x.["foo"] syntaxes (and x. at priv, too), and if you define the latter as "native property access", for the time being equivalent to [], but later [] can be redefined (or vice versa, but it seems .[] is more akin to . and .@ and [] seems better for "logical" element access), you've got the collection [] but don't lose the object-structural []. > Allen Herby