Thanks, David.
First, I'd like to point out that in the blog post I'm putting on the hat
of a library author (I happen to be one, but that's beside the point).
One of the first conclusions that I come to (as a library author) is that
the idiom described here:
var Blah = BaseClass | function(){}
Blah.prototype.{
a: function(){},
b: function(){}
}
The point I'm trying to drive home is that the above is no better (worse,
in fact) from a user experience standpoint, than what I have now. To be
blunt, I would not use the above
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
Hi Allen,
In this stawmanhttp://wiki.ecmascript.org/doku.php?id=strawman: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?
kevin
___
es-discuss mailing list
As far as I have understood Total Function Expressions is supposed to
return all functions that do not contain this in their initial scope and
that have a var self=this trick that is used somewhere inside the
function (ie function() {var self=this;var b=function()
{console.log('test')} is
Hi all,
I've updated the
spreadsheethttps://docs.google.com/spreadsheet/ccc?key=0Aro5yQ2fa01xdEJySWxhZ1VoZ0VaWTdldXp4NUtJd3cto
show a count of object literal methods for each sampled code base.
These are function expressions which are the values in an object literal,
and that reference this
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:
- A pain point for doing OO
Hi Herby,
I'm aware of that proposal but I'm not aware that it is still being
pursued. Is it?
kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
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.
It's not clear that obj.@name would offer any such
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.@privateName be dropped unless it can be proven that it provides
quantifiable benefit over obj[privateName].
Thanks,
kevin
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
Ironically, with a German keyboard, it is quicker to type this. than it
is to type @.
: ) Good to know.
kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
BTF is shorthand for bound-this function expressions. BTFs are
semantically equivalent to classic function expressions with the exception
that this is lexically bound.
*Methodology *
Using a modified version of the ES parser in UglifyJS, I generated an AST
for the input string. I then traverse
This is good work, but I don't think every function that doesn’t use
'this' is a supporting use case for bound-this functions, though. Many
functions are like this:
panels.each(function (p) { p.fadeIn(); });
and that function would not benefit at all from being converted to a
bound-this
The question here is, if there is a observable difference in performance
between BTF and non-BTF, and not to allow the shorter syntax only for the
less performant one (either only for the more performant one, or for both),
because shorter form will be used also when not needed.
I'm assuming
An additional note on methodology: for the applications that I looked at
(like Facebook and Netflix), I downloaded and concatenated the javascript
found when loading a typical page. I'm assuming that the original code was
written in javascript (as opposed to CoffeeScript or Java) and that
I'm confused by this paragraph. Functions that benefit from 'this'
binding would reference 'this' or an alias for 'this' right?
In this analysis, functions that reference an alias to this (e.g. var
self = this) within an inner scope are counted:
(function() {
var self = this;
Hi John,
(function() {
var self = this;
(function() { console.log(self); });
});
1. As stated above, it's assumed that BTFs will be preferred for clarity
or brevity gains, even if bound-this is not required. Opting out of BTFs
is no different than using classic
That would be suitable for conversion to a BTF, perhaps like this
(depending on syntax, of course):
$('#foo').bind('click', evt = { alert($(evt.target).text()) });
Again, this will be a case of the tool potentially undercounting BTF
candidates.
kevin
Kevin, do you have time to attempt this?
Short answer: no. : )
I think the previous analysis is undercounting potential expression
functions. Consider the following case:
IO.File.readText(path, text = { console.log(text) });
Since we don't care what the callback returns, we could
I've updated the tool to also analyze the number of formal parameters for
each BTF candidate. I've haven't had time to update the spreadsheet, but
for every body of code that I've sampled so far, 1 is the most common
number of formal parameters.
This suggests that optimizing syntax for BTFs with
Infix arrows are really nice looking aren't they? : )
kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
that contain references to 'this'
in its immediate scope.
** Function expressions whose first statement is a return.
Parameter List Length 0 17.46031746031746% 1 47.61904761904761%
230.158730158730158%34.761904761904762%4 or more0%
On Tue, Mar 13, 2012 at 8:55 PM, Kevin Smith khs4...@gmail.com wrote
If Expression covers FormalParameterList then LR(1) is enough -- we'll
know when we see that arrow (or { on same line as the ) before it). This is
considered somewhat future-hostile by some on TC39.
I need to think about cover grammars some more...
(x,y) = {p:x*y} // return an object
I don't know about implicit return. TC39 wants to avoid it in anything
that looks like a function (body). Does the = distinguish this case
enough? Consider a large body-block.
I can see the problem. I would personally rate this as less potentially
confusing than () = expr, though.
The
I doubt that (simple) statistics are equally useful here, though: the
current
syntax is sufficiently awkward that programmers actively avoid using the
very code patterns that short functions would help to make readable.
Thanks Claus - I understand but I think you're overstating. In any
it on any application
code yet.
kevin
On Sat, Mar 10, 2012 at 11:08 AM, Kevin Smith khs4...@gmail.com wrote:
I doubt that (simple) statistics are equally useful here, though: the
current
syntax is sufficiently awkward that programmers actively avoid using the
very code patterns that short
LR(1) is for granddads ; )
This is really sexy.
Question: for ShortFunctionExpression, do we need an additional = form
for this-binding a function body?
ShortFunctionExpression:
Identifier_opt ( FormalParameterList_opt ) [no LineTerminator here] {
FunctionBody }
Identifier_opt (
Knuth. Respect.
For sure - LR parsing still blows my mind (looks for his trusty dragon book
- here it is!).
We could do that and leave the arrow-free form with unbound |this|. Better
by my argument that anything based on today's function body-plan should not
start adding TCP conformance --
Anyway, I'm still trying to get something for shorter function syntax into
ES6. I think TC39 can yet make an exception if we have our validation story
figured out. That is where to focus fire.
Must it be LR(1), then? I don't think an LR parser can handle short
functions (or arrows) as we've
Sorry for the tl;dr - last post for today...
It occurs to me that we might be able to prove that the language is
something like non-deterministic LR(1). A non-deterministic LR parser
could have shift entries in it's parsing table pointing to more than one
state. When it hits a cell like that,
Thank you for the explanations. Block lambda syntax with pipes makes more
sense to me now. Given that most of the stuff I do is asynchronous though,
I personally would prioritize the semantics this way:
1. Short function syntax with lexical this.
4. Block lambdas with TCP return.
Thanks
If I understand correctly, it's still an open question whether parsing ()
= {} is feasible or not using a recursive top-down parser.
Is that right?
kevin
On Thu, Mar 8, 2012 at 10:46 AM, Russell Leggett
russell.legg...@gmail.comwrote:
Bound this would be nice, since it is a new form that
Thanks for the clear explanation, Brendan - I think I understand the
concerns now. And if not, I don't mind looking foolish : )
I just looked at the code for the Dart parser and it basically queues
tokens until it finds the matching right paren (recursively counting nested
parens). It peeks at
that we queue while attempting to
parse ( FormalParameterList ) will be identical to the token stream that we
would have queued if we had attempted to parse ( Expression ).
Thanks,
kevin
On Thu, Mar 8, 2012 at 4:28 PM, Kevin Smith khs4...@gmail.com wrote:
Thanks for the clear explanation
(weighing in just as a developer...)
So this is pretty consistent with the language and would be easy to explain
to current and future developers:
// Short function, familiar rules:
() {
// ..
}
// Lexical this, tcp and all that
() = {
// ..
}
// Or
() = expr
Pipes are fine in and of
that or prototypeof?
On Sun, Mar 4, 2012 at 5:29 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Sun, Mar 4, 2012 at 4:57 PM, felix feli...@gmail.com wrote:
A friend commented, all the symbol forms are difficult to speak over a
phone. The operator will need a common pronounceable name,
None of the syntax options presented so far seem to be winning. Would not
specifying the prototype somewhere *inside* of the object literal also be
an option? If so, would anyone like to take a crack at that?
khs
___
es-discuss mailing list
Clearly there is intrest out there for shimming these collection classes in
right now. It would seem prudent to hold off until they are part of a
finished spec though. Or not? Any advise from committee members regarding
optimistic shimming?
khs
On Wed, Feb 29, 2012 at 10:26 AM, David Herman
Not to backtrack the conversation, but I'm not convinced that delete
should be used to remove an element. Noone's going to ask me, how do I
delete an element from the set?. They're going to ask me, how do I
remove an element?. Also, I'm currently suspicious of any parallels
between deleting a
I'm sure it's been considered, but since this is es-discuss and open to any
gadfly:
Has it been considered that, regarding modules, all that developers need is
(1) a way to inform the engine, at compile time, that certain external
scripts are needed, and (2) a way to return a value from a script?
Suppose that jQuery2 is distributed as a single es-next module and I want
to distribute a module that depends on it. I would expect to be able to
write something like this:
module jQuery2 from http://code.jquery.com/jquery2.js;;
export function whizBang() {
/* Use jQuery2 */
}
The end user
I've put examples of real world code chock-full of anonymous function
expressions in both leading-char (#) and angle-braketing styles here:
https://gist.github.com/67
Feel free to continue this discussion on that page, if inclined.
khs
On Sat, Mar 26, 2011 at 10:44 PM, Brendan Eich
As a simple matter of taste, I find the # symbol to be quite ugly and have
been thinking of alternatives for shortening function expression syntax.
In working with my own wonky version of promises, I continue to make the
same typing error over and over again. This is something like what I mean
Oh, boogers! : )
On Fri, Mar 25, 2011 at 1:24 PM, Mike Samuel mikesam...@gmail.com wrote:
2011/3/25 Kevin Smith khs4...@gmail.com:
As a simple matter of taste, I find the # symbol to be quite ugly and
have
been thinking of alternatives for shortening function expression syntax
}
; // noop
AnObject.prototype.methodCall(value);
{
// another block
}
; // noop
On 25 Mar 2011, at 17:28, Kevin Smith khs4...@gmail.com wrote:
Oh, boogers! : )
On Fri, Mar 25, 2011 at 1:24 PM, Mike Samuel mikesam...@gmail.com
wrote:
2011/3/25 Kevin Smith khs4...@gmail.com
I don't know about insertion order being important, but certainly it's
natural to want to express order with object literals (or equivalently,
JSON). If we can't rely on enumeration order matching key ordering in the
literal, then the programmer has to express that ordering twice: once
keywords can already be used after a '.'
or before a ':' in object literals.
Dave
On Dec 28, 2010, at 7:34 AM, Kevin Smith wrote:
In the modules strawman, module is a keyword, right? Will code that
uses module as an identifier most likely cause a syntax error?
Thanks
Sweet - I was hoping that the module wouldn't have to name itself.
My next question has to do with bundling. Let's say I want to bundle a.js
and b.js into a single file, with the exports of a.js providing the exports
of this bundled thing. I suppose I could wrap both of the individual
modules
{
// original b.js contents ...
}
// original a.js contents ...
}
But I'm not sure if I'm getting what you want the example to be.
Dave
On Dec 28, 2010, at 10:41 AM, Kevin Smith wrote:
Sweet - I was hoping that the module wouldn't have to name itself.
My next question has
If I might ask a side-question: what's the value in making an object
non-extensible in ES5? I understand the value of making properties
non-configurable or non-writable, but I don't yet see a reason to prevent
extensions.
Thanks!
Kevin
On Thu, Dec 23, 2010 at 3:18 AM, Brendan Eich
From my perspective as a JS programmer, overloading the dot seems confusing.
The gains in elegance don't appear to me to be worth it. However,
overloading [] might be more acceptable:
let x = new PrivateName();
// or perhaps:
private x;
function Point()
{
this[x] = 100;
}
function
901 - 952 of 952 matches
Mail list logo
