Le 28/07/2013 08:53, Steve Fink a écrit :
On Fri 26 Jul 2013 12:29:10 PM PDT, Brendan Eich wrote:
Steve Fink wrote:
(2) writing JS still feels clunky in comparison to writing
Python,
What's missing in your experience?
That question deserves a proper response, but it's tough remembering
the issues when I'm not actively hacking out code. I've attempted to
make lists of stuff at various times that I can dig up, but for now
I'll just list out some that I've noticed recently. These are things
that are possible but seem a little indirect or unnatural:
Allowing myself to comment and add some feedback from my experience with JS.
* copying an array with copy = orig.slice(0). Compare with Python's
copy=list(orig) or copy=dict(orig), or Perl's @copy = @orig or %copy =
%orig.
Yes. A .copy would be nice for arrays.
This reminds me of something else. Recently [1], Angus Croll asked for
Array.prototype.last. A bunch of people replied with some code to do
that, but there is always a risk that a standard version comes along
with different edges (non-dense array case, etc.). Interestingly,
someone made it a method, someone else a getter... It's only safe to
polyfill if there is a spec.
I'll bring that to es-discuss.
* using an array for a tuple feels heavyweight. |return [a,b]|. Compare
with Python's tuples or Perl's multiple return values.
The "tradition" in JS is to return an object and give names to the keys.
It usually makes the code more readable as one doesn't need to remember
the semantics of each field ("is the second element of the array to
latitude or longitude?")
* |if (!(item in collection))|. I miss Python's |if (item not in
collection)|
YES! Especially to work around |if(!'yo' in obj)| (turns into |if(false
in obj)| which is never what people want)
* Not a language issue, but I really like the cleaner control flow and
intermediate memory usage of generators. But I am avoiding them in hot
code because neither ionmonkey nor baseline currently gets along with
them. (As in, they don't compile them, so I've been advised to avoid
them when I don't want a performance cliff.)
:-/ I would take the other road, that is: use them as you need and
create a benchmark out of your real code so that IonMonkey and Baseline
have an actual use case (and motivation!) to optimize.
Chicken and egg problem, but if no one uses them, they'll never get
optimized.
On a related note, has the SpiderMonkey team heard of JSRegress [2][3][4]?
* Extending an array via |combined = orig.concat(newstuff)| creates
garbage, can't be used when updating the original is what you want, and
concat behaves differently for arrays vs everything else. (I don't know
the spec well enough to understand what "array" means in this case.)
Compare with Python's orig.extend(newstuff) and Perl's push @orig,
@newstuff.
Little known fact: Array.prototype.push is variadic, so you can do:
Array.prototype.push.apply(orig, newstuff) // ES5
or
orig.push(...newstuff) // ES6 assuming
https://bugzilla.mozilla.org/show_bug.cgi?id=762363
* undefined testing. It bothers me that |undefined| can be defined, so
|x === undefined| isn't 100% guaranteed to mean what I want (and yet
redefining undefined doesn't do anything useful.)
ES5 made 'undefined' an own non-configurable, non-writable value
proproperty of the global object. So the global undefined variable can't
be changed; guaranteed per spec. http://es5.github.io/#x15.1.1.3
Changes to the "undefined" variable can only happen if someone changes
the value in one of your function scopes. If you control your scopes,
you control the value of the undefined variable. (basically, if in your
file, no function declares an "undefined" variable or argument, the
value is guaranteed to be the global one and not to change according to
the above point).
Hope that helps,
David
[1] https://twitter.com/angustweets/status/359827047117373443
[2] https://github.com/WebKit/webkit/tree/master/LayoutTests/fast/js/regress
[3] https://mail.mozilla.org/pipermail/es-discuss/2013-July/031816.html
[4] https://mail.mozilla.org/pipermail/es-discuss/2013-July/031819.html
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
