@name
@ is also sort of planned as a syntax to access private properties of an object.
Also mentioned in this thread: esdiscuss/2012-January/019876
I'm aware of that proposal but I'm not aware that it is still being pursued. Is it?
Kevin Smith wrote:
Hi Herby,
I'm aware of that proposal but I'm not aware that it is still being pursued. Is it?
AFAICT from the discussion it is the winning alternative (so far). But someone at higher position must tell for sure.
Minification considerations aside (where compression should help), that point seems to be highly controversial: I, for one, much prefer this to any kind of shorthand. The brain works with tokens, so grawlix and words have similar cognitive load. Even for private names, I’d rather have regularity via this. at privateName than terseness.
Obviously, mine is just one opinion among many, but not everyone wants this gone. The .{ operator or some variant of it should also help with verbosity.
Opinions are opinions, sure, but in the real-world example that I posted, "this." appears a staggering 49 times. And that's for a relatively simple class. Tastes aside, eliminating that repetition would offer quantifiable benefit.
It's not clear that obj. at name would offer any such benefit. If anyone has done any research, I would be glad to know.
I just want to make sure the numbers are out there.
Kevin Smith wrote:
Hi Alex,
Opinions are opinions, sure, but in the real-world example that I posted, "this." appears a staggering 49 times. And that's for a relatively simple class. Tastes aside, eliminating that repetition would offer quantifiable benefit.
Since foo. at bar is a candidate for private name, you can suggest
- @ itself to be abbreviation to this. But it is grawlixy, I don't know if people will like the code like this:
function SkinnedMesh(geometry, materials) { THREE.Mesh.call(@, geometry, materials); @.identityMatrix = new THREE.Matrix4(); @.bones = []; @.boneMatrices = []; // ... };
not to mention that private access would be @. at foo.
-
another suggestion (use another char for 'this' or glued with foo as replacement for 'this.foo')
-
one thing I came with is to use '()' in place of this. Also a bit grawlixy, but can have some logic to it (empty parentheses returning the default value, which is this since we're OO :-) ), the code may look like this:
function SkinnedMesh(geometry, materials) { THREE.Mesh.call((), geometry, materials); ().identityMatrix = new THREE.Matrix4(); ().bones = []; ().boneMatrices = []; };
which is maybe readable... but grawlix-dislikers would not like it (I also do not like grawlix too much. like in perl) and shorteners will probably not be happy that is only saves two chars per this.
Sorry, but to be clear I'm suggesting an alternate usage for @ consistent with CS. I'm also suggesting (somewhat subversively) that the proposed syntax obj. at privateName be dropped unless it can be proven that it provides quantifiable benefit over obj[privateName].
Thanks,
On Mar 14, 2012, at 10:22 AM, Kevin Smith wrote:
Hi Herby,
Sorry, but to be clear I'm suggesting an alternate usage for @ consistent with CS. I'm also suggesting (somewhat subversively) that the proposed syntax obj. at privateName be dropped unless it can be proven that it provides quantifiable benefit over obj[privateName].
The reason to not require obj[primateName] as the primary syntax for accessing private named properties is that it clashes with the goals of Object Model Reformation proposal [1], either immediately in ES6 (which some would like to see) or in a future editions.
If obj[privateName] is the only way to access a private named property then objects that redefine the semantics of [ ] such as ReformedArray[2] or HTMLCollectionArray[3] could not easily also have private named properties, which are essential for their implementation.
The obj. at privateName and defining private named properties in object literals as {@privateName1: expr, @privateName2 () {}} permits private name properties to easily co-exist linguistically with extensible obj[expr] semantics.
An essential part of the obj. at privateName semantics that the identifier following the @ is evaluated as a variable reference to obtain the property key value. That means that this. at foo only works if foo is defined as an in scope variable (or const) binding. It is not equivalent to obj.foo which literally uses "foo" as the property key. Under this semantic, @foo could be recognized as an abbreviation for this. at foo but it would not mean the same thing as this.foo. Of that reason, I think the abbreviation would problematic.
Extensible [ ] as proposed in [1] in conjunction with obj. at privateName adds new expressability to the language. It lets you do things that couldn't be done before. @name as a simple appreciation for this.name adds nothing new to the language. Given a choice between the two, I would go with the enhanced expressability.
Allen
[1] strawman:object_model_reformation
[2] strawman:object_model_reformation#reformed_array
[3] strawman:object_model_reformation#rationalizing_dom_htmlcollections
On Mar 14, 2012, at 9:15 AM, Herby Vojčík wrote:
Kevin Smith wrote:
Hi Herby,
I'm aware of that proposal but I'm not aware that it is still being pursued. Is it?
AFAICT from the discussion it is the winning alternative (so far). But someone at higher position must tell for sure.
I'm going to bring it up for discussion at the next TC39 meeting.
On Mar 14, 2012, at 9:19 AM, Axel Rauschmayer wrote:
Minification considerations aside (where compression should help), that point seems to be highly controversial: I, for one, much prefer
thisto any kind of shorthand. The brain works with tokens, so grawlix and words have similar cognitive load. Even for private names, I’d rather have regularity via this. at privateName than terseness.Obviously, mine is just one opinion among many, but not everyone wants
thisgone. The .{ operator or some variant of it should also help with verbosity.
I agree. Program readability should always be prioritized ahead of saving keystrokes when writing code. Same goes for minimization. If a minimized (over and above what we can get with compression) form of the language is important then we should define a minimized non-human directed alternative syntax rather than making the human readable expression of the language less readable.
self invocation (eg, this.foo()) is probably the key idiom of object-oriented programming. It is important that it stands out when reading code. Smalltalk required an explicit "self" for self invocations. The self language tried to innovate by not requiring an explicit self based upon the premise that self invocation was so fundamental that only non-self invocations needed to be syntactically explicit. However, personally I think that experiment was a failure as I have always found self code much harder to read than Smalltalk code.
Same goes for Java and C# where the this is optional. Using some sort of marker symbol (such as @foo as an abbreviation of this.foo) helps the reader distinguish self calls from regular function calls but it is debatable whether that grawlix form is as readable than a simple this.foo.
Thanks, Allen. I understand the issues better now.
Same goes for Java and C# where the this is optional. Using some sort of marker symbol (such as @foo as an abbreviation of this.foo) helps the reader distinguish self calls from regular function calls but it is debatable whether that grawlix form is as readable than a simple this.foo.
It would be interesting (although perhaps not feasible) to do readability studies on these and other syntax matters.
Same goes for Java and C# where the this is optional. Using some sort of marker symbol (such as @foo as an abbreviation of this.foo) helps the reader distinguish self calls from regular function calls but it is debatable whether that grawlix form is as readable than a simple this.foo.
Ironically, with a German keyboard, it is quicker to type "this." than it is to type "@".
Pitching in a bit. Heh, its seems to me like a lot of people will be happy when/if we eventually get macros in.
If this is really a too long word to type or takes too many characters (I'm not saying it is, I don't really have an opinion on... this.), what about this (may be flat out stupid, but just throwing it out there):
.aPropertyOfThis = something;
Obviously this requires a semicolon before it to work, but at least it seems pretty obvious to me what it does. At first glance it seems to me it's LR (1) compatible as well, so no prob there. Of course it can't replace 'this' when you're not referring to a property.
Another option, to avoid forced semicolons:
..aPropertyOfThis = something;
But this can't have an non-float number before it, without semicolon. I don't think it's a big problem though.
If you want to reference this directly, maybe something like this:
Dog.prototype.barkAt.call(., neighbour);
or...
Mole.prototype.plant.call(.., neighbour.backyard);
But those look quite a bit funky and scary to me, resemble typos too much.
Ironically, with a German keyboard, it is quicker to type "this." than it is to type "@".
: ) Good to know.
Ironically, with a German keyboard, it is quicker to type "this." than it is to type "@".
Alt Gr + 2? Yeah, that's why I'm using a US keyboard, although I'm Finnish. :) Easier to live with missing umlauts than with alt gr layouts.
It would be interesting (although perhaps not feasible) to do readability studies on these and other syntax matters.
Very true, that would add a different quality to the discussion. But I wonder if even that would change the strength with which people feel (positively or negatively) about CoffeeScript-ish syntax. I think that CS has a syntactic style that is quite different from JS (probably for the better, just imagine how confusing things would be once ES6 is in wider use...). That’s why I’m not sure that mixing the two styles is a good idea. And that’s why I prefer Allen’s proposal over arrow syntax.
That’s why I’m not sure that mixing the two styles is a good idea.
I agree. I'm not a CS user and I personally prefer C-ish syntax, but I'm perfectly willing to steal ideas that might work.
I'm still hoping that ES.next includes declarative classes, and according to the strawman harmony:classes,
one of the open issues is syntax for accessing private members. @name might work well for that.
Kevin Smith wrote:
That’s why I’m not sure that mixing the two styles is a good idea.I agree. I'm not a CS user and I personally prefer C-ish syntax, but I'm perfectly willing to steal ideas that might work.
I'm still hoping that ES.next includes declarative classes, and according to the strawman harmony:classes, one of the open issues is syntax for accessing private members. @name might work well for that.
Slightly off-topic, but for example me, I very hope the classes (as per the cited strawmen) will not be included, because the syntax is (imo) bad in principle, creating classes as another special case of {...} block. (I am a bit paranoic, so I had the urge to show there is different opinion, too)
And I do not like CS nor C syntax. I'd prefer Smalltalkish one (though I am not suggesting it, ES is C-derived, so C-derived it should stay).
kevin
Herby
P.S.: I find -> syntaz awkward as well, but I believe it is a matter of
familiarity. Those that are familiar with it from Haskell etc. will probably have no problem read it; as well as I have little problem to read {|x, y| x+y} or {:x, :y x+y} as a replacement for function returing sum of their two arguments...
In this stawmanstrawman:private_names,
private members are accessed using obj.name, where "name" can be a private name that is in scope. Why was this strategy abandoned?
On Thu, Mar 15, 2012 at 10:30 AM, Kevin Smith <khs4473 at gmail.com> wrote:
Hi Allen,
In this stawmanstrawman:private_names, private members are accessed using obj.name, where "name" can be a private name that is in scope. Why was this strategy abandoned?
This conflates lookup by object key vs. string key and could be incredibly confusing. And what happens when you have a private name locally scoped to the symbol "foo" and a string key "foo"?
On Mar 15, 2012, at 7:30 AM, Kevin Smith wrote:
Hi Allen,
In this stawman, private members are accessed using obj.name, where "name" can be a private name that is in scope. Why was this strategy abandoned?
kevin
There was significant negative feedback on this list WRT that version of the proposal.
See the long thread starting at esdiscuss/2010-December/012299 and other related threads in December 2010.
It would probably be a good idea for me to go back and re-read all of those threads, but main recollection of the main issues were:
- Many people believed that the parallel name spaces for variables and private names was too confusing:
private x; //declare x as a private name
function (p,x) { //declare x as a parameter, it does not shadow private name x
p.x = x; // .x resolved using private name scoping, RHS x resolved using normal declaration scoping
}
-
Many people (not necessarily the same people in all cases) did not like the fact that the existing identify:
obj.name is always equivalent to: obj["name"]
was lost.
There did not appear to be any chance of consensus forming around this proposal so backed of to the current, much simpler private name proposal that does not have a |private| declaration (and hence introduces no new scoping issues) and which only supports obj[nameValuedExpression] as a syntax for accessing private named properties. The idea was to make the proposal as simple as possible so we could get agreement on it.
On Mar 15, 2012, at 7:45 AM, Dean Landolt wrote:
On Thu, Mar 15, 2012 at 10:30 AM, Kevin Smith <khs4473 at gmail.com> wrote: Hi Allen,
In this stawman, private members are accessed using obj.name, where "name" can be a private name that is in scope. Why was this strategy abandoned?
This conflates lookup by object key vs. string key and could be incredibly confusing.
The way I would this as: there isn't a sigil at the point of reference that distinguish a private named property reference from a normal string property name reference:
obj.name
might be referencing either a property whose key is "name" or a property whose key is a private name whose value is bound to the identifier name. The actual meaning is only determined by whether or not a private declaration for the identifier name is within scope of the reference. This will be confusing if you are oblivious of the enclosing private declarations.
And what happens when you have a private name locally scoped to the symbol "foo" and a string key "foo"?
obj1.foo = obj2["foo"]
however, I would now have the same concerns about this WRT 1 as do about the current proposals:
obj1[privateFoo] = obj2.foo;
Still not sure if I like this, but I wanted to point out that there's no syntax conflict between @ as a 'this' and 'this.' shorthand and obj. at name, as far as I can tell.
The only weirdness would be this:
this. at name
vs
@@name
Otherwise they seem to conflict no more than object literals, labels and conditional operators. Is this correct?
Axel Rauschmayer wrote:
It would be interesting (although perhaps not feasible) to do readability studies on these and other syntax matters.
Very true, that would add a different quality to the discussion. But I wonder if even that would change the strength with which people feel (positively or negatively) about CoffeeScript-ish syntax. I think that CS has a syntactic style that is quite different from JS (probably for the better, just imagine how confusing things would be once ES6 is in wider use...). That’s why I’m not sure that mixing the two styles is a good idea. And that’s why I prefer Allen’s proposal over arrow syntax.
You mean do (params) {stmts}? The objection there (from dherman and me at least) is that "do" means immediately-invoke as in do expressions, IIFE sugar (CoffeeScript's do, useful for capturing var bindings in a loop), and Smalltalk do: selectors. It does not mean "defer" -- "do later".
It's a bit of an abuse of an existing keyword. It helps to have a keyword in front, but not any keyword. Rather "fn" but will that really win adoption given the "function" legacy.
Jeremy Ashkenas tweeted “For the record, I too favor [block lambdas] if arrows in JS will need curlies to delimit blocks. Curlies or arrows, not both.” This is another blow (I mentioned two yesterday) against
(params) -> {stmts}
If we only add
(params) => assign-expr
and put this at the AssignmentExpression level in the grammar, then we almost have consensus. The remaining issue is agreeing that (expr) covers (params), forever. I'm hopeful we'll manage to reach consensus there.
Then the (separate) do-expression strawman, with full TCP, composes fairly nicely (four chars linkage):
(params) => do {stmts}
The lack of unbound-this and non-TCP function body, i.e., the lack of thin-arrow, means users have to reach for plain-old-function still. This may be ok. Kevin's numbers say ~10% cohort.
Fat-arrow-only (plus do-expressions) looks like the minimal and likely winner.
Kevin Smith wrote:
That’s why I’m not sure that mixing the two styles is a good idea.I agree. I'm not a CS user and I personally prefer C-ish syntax, but I'm perfectly willing to steal ideas that might work.
I'm still hoping that ES.next includes declarative classes, and according to the strawman harmony:classes, one of the open issues is syntax for accessing private members. @name might work well for that.
Definitely, but classes have bigger issues than private syntax, and have for a while. Class-side inheritance, body syntax, whether there should be any declarative public syntax, what nested classes mean, static or 'class' members -- that's a partial list from memory.
Minimal classes based on object literals could be done but seem too minimal. As Waldemar suggested and Allen has worked to develop, they tend to collapse into object literals (with smaller extensions).
Fat-arrow-only (plus do-expressions) looks like the minimal and likely winner
Based on my experience with translating real world code to "try out" this syntax, it would be an incredible win.
IIUC, it also leaves open the possibility of (params) -> {} in the far future - after the world has become accustomed to seeing an "arrow" as a function. Maybe? Maybe not?
Sure, can always do more based on deferred strawman parts.
I think that CS has a syntactic style that is quite different from JS (probably for the better, just imagine how confusing things would be once ES6 is in wider use...). That’s why I’m not sure that mixing the two styles is a good idea. And that’s why I prefer Allen’s proposal over arrow syntax.
You mean do (params) {stmts}?
The objection there (from dherman and me at least) is that "do" means immediately-invoke as in do expressions, IIFE sugar (CoffeeScript's do, useful for capturing var bindings in a loop), and Smalltalk do: selectors. It does not mean "defer" -- "do later".
The way I interpret the syntax for me is: Adding parameters to a block delays its execution (loosely like quoting in Lisp).
Jeremy Ashkenas tweeted “For the record, I too favor [block lambdas] if arrows in JS will need curlies to delimit blocks. Curlies or arrows, not both.” This is another blow (I mentioned two yesterday) against
(params) -> {stmts}
If we only add
(params) => assign-expr
and put this at the AssignmentExpression level in the grammar, then we almost have consensus. The remaining issue is agreeing that (expr) covers (params), forever. I'm hopeful we'll manage to reach consensus there.
Then the (separate) do-expression strawman, with full TCP, composes fairly nicely (four chars linkage):
(params) => do {stmts}
The lack of unbound-this and non-TCP function body, i.e., the lack of thin-arrow, means users have to reach for plain-old-function still. This may be ok. Kevin's numbers say ~10% cohort.
Fat-arrow-only (plus do-expressions) looks like the minimal and likely winner.
Given that TCP support is something new, the above looks and feels OK. Should grammar complexity be an obstacle, we still have block lambdas and Allen’s proposal.
Two things I feel strongly about:
-
Don’t introduce another way of defining current functions (apart from
fn). The combination of abbreviated method syntax in object initializers, TCP/implicit return “blocks” andfnshould be enough. -
Don’t introduce two kinds of arrows to distinguish between lexical and dynamic
this. Currently, things are very confusing to newbies. Either the solution you mention above or what Allen proposes would help tremendously, because people would automatically do the right thing. With two arrows, code written by experts would become hard to understand for newbies.
Axel
One thing that has come up in my number crunching is the repetition of the character sequence "this.". If we allowed @ (ala CoffeeScript) as a shorthand for "this.", then we could, if nothing else, shave perhaps 1-3% off of the size of minified code.
Other advantages:
See this example gist.github.com/2007371. (This example describes
a hypothetical class syntax, which I'm not proposing in this thread. But it does illustrate the @name concept.)