RE: Existential operator (was: ||= is much needed?)
What struck me from Jeremy's explanation was the uniformity of CoffeeScript's ? operator (modulo the small issue he mentioned for function calls). It seems to combine the currently-strawman'ed ??/??= and ?. into one very simple semantic. What about adopting ?? as CoffeeScript's ? operator? Would this solve the lookahead problems? So you could do object.property??.other.properties.go.here object.method??(args) This would unfortunately imply, for uniformity, that object ?? other object ??= other become null + undefined tests instead of just undefined. But that might be worth paying. For the record that leaves object?? as the only unimplemented CoffeeScript counterpart. From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Brendan Eich [bren...@mozilla.org] Sent: Tuesday, June 19, 2012 14:08 To: Jeremy Ashkenas Cc: es-discuss Subject: Re: Existential operator (was: ||= is much needed?) Jeremy Ashkenas wrote: Everywhere else in the language, `?` means existence (not null or undefined) -- but when used to call a function, the check ensures that the value is callable as well. In a DWIM sense, this makes sense, because the only things you'd ever want to try to call in JavaScript must be callable ... but I think it's strange that the meaning of existence alters itself just for this use case. I opened a ticket talking about rolling it back to null or undefined semantics here: https://github.com/jashkenas/coffee-script/issues/2315 Apart from people misreading the proposal in this issue, it does seem to be removing a bit of utility, but perhaps that's not actually used? Do CS users try to ?(-invoke a maybe-function that is sometimes neither null nor undefined nor typeof-type function, but rather something that coerces to object? The way to get ?( into JS is by a longer spelling: options.success?.(response) Pretty ugly, but it puts the ? magic right where the maybe-test belongs. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
In our experience writing large apps, the distinction is useful. Undefined
means I forgot to do something (e.g. set a property or pass an argument); null
means I tried to get something but it didn't exist.
Very roughly, it becomes undefined = caller error outside of my control, null =
my error and I should use the API more correctly.
On Jun 14, 2012, at 11:27, John Lenz
concavel...@gmail.commailto:concavel...@gmail.com wrote:
My two sense. In my experience (large applications, rather than tight
libraries), distinguishing between null and undefined is the exception, not the
rule. When it is distinguished, as often as not the author would be more
correct in either including null or making an property existence check (foo in
bar) rather than an explicit check for undefined.
On Wed, Jun 13, 2012 at 11:18 AM, Brendan Eich
bren...@mozilla.orgmailto:bren...@mozilla.org wrote:
Tab Atkins Jr. wrote:
Okay, further testing shows that my knowledge was incomplete. Null
and undefined compare as double-equal, but neither are double-equal to
other falsey values.
This is intentional, believe it or don't :-P.
In ancient days, void 0 was the only way to spell undefined, and users
immediately tested o.p != null to existing-check. There was even some confusion
where missing array elements in primordial JS evaluated to null not undefined.
Argh, I had made myself forget that, now I remember.
However, my argument stands - being undefined-specific is not
arbitrary, because that's what is actually returned by such things.
Both args without values and properties that don't exist give the
value undefined when you try to reference them.
Agree still. I do not see use-cases for including null. Maybe they exist,
though -- someone please cite some github-hosted JS.
Even the Node workaround/premature-optimization of storing null rather than
using delete doesn't argue for defaulting based on LHS value in {null,
undefined}.
Using a double-equal
check against null to test for whether something is undefined only
works because double-equal is pretty screwed up.
It is screwed up but for reasons. Bad reasons, kind of like history or biology.
Not just Homer Simpson Life is just a bunch of things that happen randomness,
mind you! :-P
The most principled reason I've heard, IIRC from @jashkenas, is that null and
undefined are confusingly similar, in part due to being ==. This is true, but I
still do not see actual use-cases where null is passed into code that uses ||
to select a default value. Would love to see such real-world code.
/be
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
On Jun 14, 2012, at 14:03, Rick Waldron waldron.r...@gmail.commailto:waldron.r...@gmail.com wrote: On Thu, Jun 14, 2012 at 11:58 AM, Domenic Denicola dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote: In our experience writing large apps, the distinction is useful. Undefined means I forgot to do something (e.g. set a property or pass an argument); null means I tried to get something but it didn't exist. null is intentional, its presence is explicit -- doesn't this imply that something _does_ exist? (...and its value is null) eg. https://gist.github.com/2926029 Rick Right, I wasn't exactly clear—I meant more the case of e.g. nothing exists in the database, so I gave you back a null or even there wasn't any error, so I called you back with a null as the first param. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Error stack
Machine-parsability might be reaching too far, especially if you lose the
benefits of nice function/method name inference. Instead, perhaps a separate
strawman to standardize something like the V8 stack trace API [1]?
It is used in Node for providing long stack traces [2], [3], [4]. It's a bit
cumbersome, e.g. maybe a separate error.stackFrames getter would be nicer and
the Java-style getFileName() methods could become simple properties. But the
fact that it exists is extremely useful.
[1]: http://code.google.com/p/v8/wiki/JavaScriptStackTraceApi
[2]: https://github.com/tlrobinson/long-stack-traces
[3]:
https://github.com/kriskowal/q/blob/0c1ffdc50a6ea77c3e97075fab35ab9f7b2d/q.js#L261-405,
https://github.com/kriskowal/q/blob/0c1ffdc50a6ea77c3e97075fab35ab9f7b2d/q.js#L1307-1321
[4]:
https://github.com/NobleJS/WinningJS-todo/commit/2d4ca10c4f672dac9f021b697c4c72bbff321ed9
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Erik Arvidsson [erik.arvids...@gmail.com]
Sent: Thursday, June 07, 2012 16:39
To: Jason Orendorff
Cc: es-discuss@mozilla.org
Subject: Re: Error stack
On Thu, Jun 7, 2012 at 1:12 PM, Jason Orendorff
jason.orendo...@gmail.com wrote:
This isn't machine parseable in all cases, since the .message may
contain newlines and can end with something like \n at ...
That is a good point. This also applies to the name of a function
(and object when included). It is trivial to create a function name
that breaks the V8 style formatting. SpiderMonkey gets away with
this by using the name of the function expression and it does not try
to deduce a name based on the code..
window['\n@'] = function() {
alert(new Error().stack);
};
When I first set out to write the proposal I was set on the
SpiderMonkey formatting but as I researched this I drifted closer and
closer to the V8 formatting. The thing that convinced me was eval.
I also don't think that providing ErrorName: ErrorMessage is a hard
requirement. The same information is already available using
errorObject.name and errorObject.message.
If we remove the first line and require that non identifiers are
quoted I think we can guarantee that the value is machine parseable
again.
Changing this in Firefox would affect any Firefox addons that use
Error.stack, but maybe we can take that hit.
For web apps we already have to parse two different versions so I'm
not too concerned about that case. The WebKit mobile web does not
depend on either format (Safari doesn't have it in any shipping
version yet) so the two problematic big eco systems are Firefox and
Chrome extensions (and Node.js?)
--
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: super, methods, constructors Co.
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Allen Wirfs-Brock
Sent: Friday, June 01, 2012 04:05
We haven't eliminated the ability to define object literals that inherit
from objects other than Object.prototype. We have just changed the
syntax for specifying them from:
proto | {}
to
{__proto__: proto}
For anyone who (like me) was confused by this in light of all the talk that
colons in object literals always do a [[DefineOwnProperty]], there is an
exemption made for __proto__ in section B.3.1.3 of the latest spec.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: arrows and a proposed softCall
-Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss- boun...@mozilla.org] On Behalf Of Mark S. Miller Sent: Thursday, May 31, 2012 22:24 Non-strict mode is so bizzarre that I wouldn't be surprised, but I can't think of an example. Is my proposed rule unsound as stated, since it doesn't distinguish strict and non-strict functions? Is there some way for a non-strict function that doesn't mention this and does not contain a direct eval operator to nevertheless be this-sensitive? I can't quite find the answer: would setTimeout/setInterval/setImmediate have the capabilities necessary? I would assume they all behave as indirect eval, but since they are outside the language spec, it seems possibly implementation-dependent. Other candidates are window.execScript in IE or vm.runInNewContext in Node, but I think both of those are explicitly global scoped, and thus could not reference this. Nevertheless, the idea of implementations providing specific methods with the same abilities as direct eval seems possible. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Subclassing built-in constructors
-Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss- boun...@mozilla.org] On Behalf Of Brendan Eich Sent: Saturday, May 26, 2012 15:08 New syntax may some day clean all this up but the short path wins and it'll be hard to displace. Let's be realistic. I agree we should, assuming classes make it, support DOM subclassing. That is good but it won't relieve DOM implementors from supporting __proto__. Is there a parallel to be drawn with __(define|lookup)(Getter|Setter)__, or is __proto__ different? I quite liked Allen's blog post about why IE decided to never support them [1]. Following that reasoning seems to lead to specifying Object.setPrototypeOf as a __proto__ replacement, and hoping library authors follow suit in switching to that from __proto__, just like they did for the property API. http://blogs.msdn.com/b/ie/archive/2010/08/25/chakra-interoperability-means-more-than-just-standards.aspx ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: minutes, TC39 meeting Tues 5/22/2012
The prototyping efforts are appreciated, but can rarely be used in a comfortable way. (Compared to, say, HTML5.) I've thought a lot about how to feasibly use Harmony features in real-world code, but have fallen down every time. Here are some of the stumbling blocks I've encountered: * Node.js with --harmony flag gets you collections, old proxies, and (significantly) block scoping. But Node does not make it easy to indicate this file needs to be run with --harmony, or e.g. to require harmony-using files from non-harmony-using libraries. So this ends up being a nonstarter for library authors, leaving it only usable by application writers. Besides, the proxies are still old, which is really unfortunate. And the iteration rate is slowww: stuff like destructuring has been harmonized for a long time, but shows no sign of making it into V8. * The same problems apply to desktop apps written with Chromium Embedded Framework. These will probably have more app code, but then if you want to factor any of it out into smaller redistributable modules, you limit your audience. * SpiderMonkey has a lot of stuff that we would love to use, and a fairly fast iteration time. (Direct proxies are almost landed, according to my bugmail!) The spec is tracked pretty well, too. But SpiderMonkey has very little uptake outside of Firefox, and most code written for Firefox must be web-compatible, so nobody except Firefox extension authors gets to use its many features. * Traceur seems to be coming along nicely, but its alignment with the spec leaves a lot to be desired. Destructuring just got fixed a few days ago, and they have a class syntax you have to avoid to write ES6-as-it-is--compatible code. They have features like private names that are not (really) in the spec yet, using speculative syntax (`new Name` was never harmonized, was it?). Monocle-mustache is in, somehow. Etc. It's ES6-like, but doesn't reflect TC39's actual progress, instead reflecting the Traceur team's interpretation of where TC39 might eventually, hopefully, end up. Subsetting might be a solution, assuming the semantics of the subsetted features are aligned with the spec, but determining that would require further investigation. * And of course there's the usual elephant in the room, viz. Internet Explorer. We (Barnes Noble.com) reached out to Microsoft about including some basic, already-harmonized features in IE10 for use in writing desktop apps in HTML5/JS as per their new Windows Runtime framework. (This was desired since we are using some of them in our existing Chromium-based desktop app, namely block scoping and weak maps.) But even as a first class partner (or something), they were unable to grant us this request. The attitude that I personally inferred was that ES6 won't make it into IE before a finalized spec is available. This not only stalls web progress, but also that of anything that embeds Chakra (a fairly common operation on Windows, about to become much more common with Windows 8). -Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss- boun...@mozilla.org] On Behalf Of Brendan Eich Sent: Wednesday, May 23, 2012 22:20 To: Brandon Benvie Cc: es-discuss@mozilla.org Steen Subject: Re: minutes, TC39 meeting Tues 5/22/2012 Play fair now. SpiderMonkey in Firefox prototyped let, const, generators, iterators (an earlier form), destructuring (close to final ES6), comprehensions, generator expressions, and more recently proxies, weak maps, maps, and sets. V8 joined in the proxies, weak maps, maps, and sets fun. The for-of loop from ES6 is in SpiderMonkey now. Most significantly, modules are under way in SpiderMonkey and V8. We prototype as we go. V8 has kept stuff under a flag and that's fair -- we may do likewise, certainly with new stuff likely to change, in SpiderMonkey. But saying nothing is coming out of TC39 is inaccurate. If you mean classes are not being prototyped because 'const class' or equivalent is not part of the almost-at-consensus maximally minimal classes strawman, you're right. If we must have a way to fix the properties of a class instance as Waldemar wishes, then I predict classes won't be in ES6 and it will be hard to justify prototyping less than the full required (as yet unwritten) proposal that satisfies everyones' wants. That is a shame, and a stain on TC39's escutcheon. But you should be accurate about the many other things we have done, which are coming along. /be Brandon Benvie wrote: The last discussion point there is really important I think. I get a strong sense of the general JS developer world feeling no connection at all to this process, and much can be put directly on the sheer timescale. We've seen 2 month browser version cycles come in force, the living standard that is HTML5 and the as of recent rapid movement of new APIs coming out to JS from not-TC39. People don't feel connected to the
RE: minutes, TC39 meeting Tues 5/22/2012
You are of course right, Brendan, and thanks for addressing my points. Certainly part of this was fueled more by frustration than informed knowledge (see below). -Original Message- From: Brendan Eich [mailto:bren...@mozilla.com] The prototyping efforts are appreciated, but can rarely be used in a comfortable way. (Compared to, say, HTML5.) Remember, HTML5 started in 2004 (WHATWG founding) and still isn't done. Eight years ago. Fair point. I think I and others would be reassured if we had some analogies drawn with the HTML5 timescale: e.g. how long from article, section etc. until they got included in default browser stylesheets, or how long from input type=date to browser UIs. (That last one is actually a pretty good example of slow implementation progress; I feel a lot better about ES6's progress when I think about how we are just now getting a UI for input type=date in Chrome.) * Node.js with --harmony flag gets you collections, old proxies, and (significantly) block scoping. But Node does not make it easy to indicate this file needs to be run with --harmony, or e.g. to require harmony- using files from non-harmony-using libraries. So this ends up being a nonstarter for library authors, leaving it only usable by application writers. Besides, the proxies are still old, which is really unfortunate. That'll be fixed this year, soon I'm told. The proxies, or Node.js? In either case, great news! And in either case, how did you learn about this? I try to stay up to date on all relevant blogs, Twitter feeds, mailing lists, etc., but certainly could have missed one. If it was private communication, perhaps in the interest of helping developers see ES6 progress (as per Brandon's original point) such things could be more publicized in the future? I imagine that's complicated though. And the iteration rate is slowww: stuff like destructuring has been harmonized for a long time, but shows no sign of making it into V8. How would you see the signs? Just asking. I know the Munich team is going strong and they have skills. I don't know detailed schedule, but there is no need to presume inaction or action. Let's ask. I guess I can't really expect to see all the signs through public channels, as above. Still, I think opening such channels would be a valuable thing for the community. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: minutes, TC39 meeting Tues 5/22/2012
From: Rick Waldron [mailto:waldron.r...@gmail.com] Etc. It's ES6-like, but doesn't reflect TC39's actual progress, instead reflecting the Traceur team's interpretation of where TC39 might eventually, hopefully, end up. I don't think this is a fair claim to make, considering Traceur had no real attention for quite some time and Erik Arvidsson really stepped it up to get a nice cross section of features prototyped in a short amount of time. I think what you meant to say was thank you. Indeed you're right, that is what I meant to say. Apologies to Erik, and thanks to JJB for pointing out Traceur is much better suited for my purposes than I thought. I will definitely give it another try. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
ToNumber(0b1001)
I was going over the latest draft and noticed that, while binary and octal literals have been introduced in 7.8.3, they weren’t added to 9.1.3.1 (“ToNumber applied to the String type”). Should they be? Pros: symmetry. Cons: breaks backward compatibility (currently ToNumber(0b1001) returns NaN). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re-throwing errors
Consider:
try {
doStuff();
} catch (e) {
console.log(uh oh, got an e, e);
throw e;
}
In Node and in all browsers I've tested with, this currently loses the stack
trace for `e`, and more importantly loses debugger step-back-ability in tools
like Firebug and Web Inspector.
One solution would be to hope V8 and the browser vendors simply don't throw
away this stack trace, like they do currently. This seems like a win to me, but
the fact that it hasn't happened implies there must be something wrong with the
idea, e.g. maybe it breaks down in less-than-trivial cases. Is that true?
If so, then in C++ and C# they solve this by saying that an empty `throw` is an
explicit re-propagation [1]. Would this be a possible feature to introduce into
Harmony?
[1]: http://winterdom.com/2002/09/rethrowingexceptionsinc
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Re-throwing errors
Eeek, how embarrassing. This seems to have been fixed while I wasn't looking,
and/or my testing wasn't as complete as I thought. I should have re-tested
before emailing. My apologies for wasting everyone's time.
The debugger step-back-ability isn't there in Chrome, at least, but that's a
much smaller problem.
From: Rick Waldron [waldron.r...@gmail.com]
Sent: Friday, May 11, 2012 16:10
To: Brendan Eich
Cc: Domenic Denicola; es-discuss@mozilla.org
Subject: Re: Re-throwing errors
On Fri, May 11, 2012 at 2:43 PM, Brendan Eich
bren...@mozilla.commailto:bren...@mozilla.com wrote:
Domenic Denicola wrote:
Consider:
try {
doStuff();
} catch (e) {
console.log(uh oh, got an e, e);
throw e;
}
In Node and in all browsers I've tested with, this currently loses the stack
trace for `e`, and more importantly loses debugger step-back-ability in tools
like Firebug and Web Inspector.
One solution would be to hope V8 and the browser vendors simply don't throw
away this stack trace, like they do currently. This seems like a win to me, but
the fact that it hasn't happened implies there must be something wrong with the
idea, e.g. maybe it breaks down in less-than-trivial cases. Is that true?
This is fascinating, but I can't reproduce - can you confirm:
https://gist.github.com/2662158
Rick
So V8 overwrites e.stack on the re-throw?
SpiderMonkey does not:
js function f() {
try {
doStuff();
} catch (e) {
console.log(uh oh, got an e, e);
throw e;
}
}
js function g() {f()}
js function h() {g()}
js function doStuff() {uh.oh}
js console = {log: print}
({log:function print() {[native code]}})
js try {h()}catch (e){E=e}
uh oh, got an e ReferenceError: uh is not defined
(new ReferenceError(uh is not defined, typein, 11))
js e.stack
typein:15: ReferenceError: e is not defined
js E.stack
doStuff@typein:11\nf@typein:3\ng@typein:9\nh@typein:10\n@typein:14\n
Since the explicit re-throw is not creating the exception object, it should not
be mutating it to clobber the original .stack value.
/be
If so, then in C++ and C# they solve this by saying that an empty `throw` is an
explicit re-propagation [1]. Would this be a possible feature to introduce into
Harmony?
[1]: http://winterdom.com/2002/09/rethrowingexceptionsinc
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: caller poison pills, revisited (Was: A few arrow function specification issues)
I'm becoming increasing convinced that the poison pill approach to securing the caller chain is a poor approach. We keep finding leaks in and it does nothing to prevent implementation from inventing new ways to expose the stating they are trying to hide. I now think we would be better off with a general,non-algorithmic restriction on conforming implementation that forbid them from exposing elements of the caller chain in the situations that the poison pills were intended to address. This sounds a bit drastic—wouldn't it preclude V8's Error.captureStackTrace? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: A few arrow function specification issues
As a day-to-day user who was not using strict until recently (stubborn other team member for the loss), I can say that moving to strict was much more a cleanup experience than a mode experience, with only a few small exceptions: 1) Poison-pilling arguments.callee: some code on the internet (notably [1], but elsewhere too) uses this property. 2) Throw on `delete`ing non-configurables: unlike the other throw-on-doing-something-bad, `delete`ing non-configurable properties was something we actually did on purpose. E.g. using it to clear an entry in a map, whether or not that entry was ever filled. (Cf. [2].) We never tried writing to a non-writable property, because that would cause bugs, but `delete`ing a property that doesn't exist was a common pattern. [1]: http://www.devthought.com/2011/12/22/a-string-is-not-an-error/ [2]: https://github.com/cjohansen/Sinon.JS/commit/80c38bd3e4b8813ab74ef27a4db3646e4778e31c --- Otherwise, it was just cleanup: we got to get rid of our global detector (`setInterval(compareWindowPropertiesToLastTimeYouChecked(), 1000)`), never missed `with` or evil-`eval`, and due to a V8 bug never had boxed `this` in the first place. We're using it transparently throughout the codebase, in fact, due to using an XHR+`eval` module loader that can insert the `use strict` pragma before `eval`ing. -Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss- boun...@mozilla.org] On Behalf Of David Herman Sent: Monday, April 23, 2012 19:11 To: Brendan Eich Cc: es-discuss Subject: Re: A few arrow function specification issues On Apr 23, 2012, at 2:44 PM, Brendan Eich wrote: Brendan Eich wrote: Without arguments runtime semantic shifts, and with |this| lexical, there aren't many strict mode changes left IIRC, and they are pretty edgy edge cases. True enough, but I hang tough on wanting arrows to imply strictness. I may be wrong but the edge cases cited so far (global variable creation by assignment, 'with', direct eval injecting 'var' into its dynamic scope) along with this |this|-boxing one are underwhelming. IMO, this decision hangs on whether we think strict mode can be thought of as a cleaning up that will mostly just catch bugs, resulting in failing faster but otherwise not changing program behavior significantly. POSITION CLEANUP: If it's just a cleanup, then it makes sense to introduce strict mode in a bunch of places in the language. It'll catch bugs, and for the most part people won't have to think to themselves is this strict code? POSITION MODE: If it's something that is likely to change behavior in meaningful ways other than failing faster, then it's something programmers will have to be mindful of. In that case, having multiple constructs that implicitly introduce strict mode imposes a burden on programmers: they have to know which features are strict and which ones aren't. Every fiber of my being screams MODE. Brendan argues CLEANUP based on the rationale that the non-error semantic changes of strict mode are unlikely edge cases. This is the strongest argument against MODE. I can't prove it wrong, but it's a risky bet. If it turns out to be the case that in practice you need to keep track of whether you're in strict mode, then weak programmers who don't know better will end up with a confusing mess, and strong programmers will prophylactically make sure to put their entire programs in strict mode rather than memorize which subset of syntaxes opt in. Since strong programmers have the option to do that anyway even without multiple implicit opt-ins, why take the risk? Pascal^H^H^H^H^H^H Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: A few arrow function specification issues
-Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss- boun...@mozilla.org] On Behalf Of Angus Croll Sent: Saturday, April 21, 2012 16:03 To: Allen Wirfs-Brock Cc: es-discuss Subject: Re: A few arrow function specification issues 4) Should it be a dynamic error to try to use apply/call to set the this binding of an arrow function. Cons To much existing code speculatively binding the this value when invoking a function. I propose that call/apply simply ignore the this value when invoked on an arrow function. What is the pro of ignoring explicit |this| binding instructions in call/apply on arrow functions? What is the con of continuing to allow legacy code to speculatively bind the |this| value when invoking any function? Why is it so important that fat arrows do a hard |this| binding? It's important, as someone who hands off an arrow function to another part of the system, to ensure that `this` means what it meant while I was originally writing the code. This guarantee is vital for predictability of behavior. Consider let mapped = array.map((el) = el * this.x) If I cannot guarantee a lexical `this`, I am back to programming with `let that = this`, which is part of what arrow functions are trying to avoid. The only alternative is reading the source code and/or spec for every system that I hand off an arrow function to, since I need to know if they will clobber the lexical `this` I was trying to program against. Note that this isn't a security issue---I'm not worried about malicious code messing me up. I'm simply trying to juggle the minimum number of factors on my precious brainstack, and when I'm trying to get a mapped array, I really don't want to think about whether `map` is going to mess with my `this`. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: try without catch or finally
Tangentially related: https://github.com/kriskowal/q/wiki/On-Exceptions
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Nebojša Ćirić [c...@google.com]
Sent: Tuesday, April 17, 2012 16:39
To: Jussi Kalliokoski
Cc: es-discuss
Subject: Re: try without catch or finally
It's easy to forget to catch in cases you wanted to.
Maybe adding a new keyword:
try {
...
} drop;
17. април 2012. 13.35, Jussi Kalliokoski
jussi.kallioko...@gmail.commailto:jussi.kallioko...@gmail.com је написао/ла:
I'm not sure if this has been discussed before, but is it a terribly bad idea
to make catch/finally optional for a try block?
There's a lot of code like this out there:
try { /* something here */ } catch (e) { /* nothing here */ }
Cheers,
Jussi
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Nebojša Ćirić
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: callable objects ?
It seems rather non-intention-revealing. From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Mark S. Miller [erig...@google.com] Sent: Tuesday, April 17, 2012 17:20 To: Brendan Eich Cc: Tom Van Cutsem; Mark Miller; es-discuss Subject: Re: callable objects ? +1 for simple enough. It's also shorter (12 vs 20) On Tue, Apr 17, 2012 at 2:02 PM, Brendan Eich bren...@mozilla.orgmailto:bren...@mozilla.org wrote: Brendan Eich wrote: This last point is important: we do not want an object's typeof-type to change by giving it a @call property. But we do want to enable call and construct protocols to be built by users, by giving objects @call and @construct properties. I did not include an Object.isCallable(v) API that returns true if (@call in v), but we could add that. Testing (@call in v) seems simple enough. /be ___ es-discuss mailing list es-discuss@mozilla.orgmailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: undefined being treated as a missing optional argument
I'm sympathetic toward `undefined` as a sentinel for no value of the expected type, whereas `null` means we have a value of the expected type, but that value represents 'nothing.' Not sure if anyone else sees it that way, though, and admittedly it's based on vague hand-wavey arguments. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Fun impossible Firefox JS challenge
The real question is, are there test-262's for this behavior? Or for the
original nonconforming `function true() { }`?
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Mathias Bynens [math...@qiwi.be]
Sent: Thursday, April 12, 2012 11:06
To: Lasse Reichstein
Cc: es-discuss Steen
Subject: Re: Fun impossible Firefox JS challenge
For those interested, Spidermonkey doesn’t handle the following correctly:
function \u0074rue() { alert('PASS'); }
\u0074rue();
function \u0074rue() { alert('PASS'); }
tru\u0065();
Both these examples should alert 'PASS' in web browsers.
I filed this as bug 744784: https://bugzilla.mozilla.org/show_bug.cgi?id=744784
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Fun impossible Firefox JS challenge
var tru\u0065; = Expected identifier error in IE9. console.log(fals\u0065) = Syntax error in IE9. Can test IE10 when I get home from work. From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Brendan Eich [bren...@mozilla.org] Sent: Thursday, April 12, 2012 13:38 To: Allen Wirfs-Brock Cc: es-discuss Steen Subject: Re: Fun impossible Firefox JS challenge Allen Wirfs-Brock wrote: 1) Understand the actual browser interop situation. For example, do all major browsers accept: var tru\u0065; SpiderMonkey shell: js var tru\u0065; typein:1: SyntaxError: missing variable name: typein:1: var tru\u0065; typein:1: ^ It looks like Carakan (Opera), JSC and V8 allow this. I can't test IE. 2) Within the constraints of 1) decide what we actually want to specify. Do we want console.log(fals\u0065) to print false or undefined? Carakan, JSC and V8 alert undefined. Anyone have IE results? Looks like SpiderMonkey implemented ES5 not ES3, probably accidentally and ahead of time. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Fun impossible Firefox JS challenge
IE10 (Windows 8 Consumer Preview edition): var tru\u0065; = The use of a keyword for an identifier is invalid console.log(fals\u0065) = Syntax error So same thing but better error message for the former case. -Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Domenic Denicola Sent: Thursday, April 12, 2012 13:49 To: Brendan Eich; Allen Wirfs-Brock Cc: es-discuss Steen Subject: RE: Fun impossible Firefox JS challenge var tru\u0065; = Expected identifier error in IE9. console.log(fals\u0065) = Syntax error in IE9. Can test IE10 when I get home from work. From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Brendan Eich [bren...@mozilla.org] Sent: Thursday, April 12, 2012 13:38 To: Allen Wirfs-Brock Cc: es-discuss Steen Subject: Re: Fun impossible Firefox JS challenge Allen Wirfs-Brock wrote: 1) Understand the actual browser interop situation. For example, do all major browsers accept: var tru\u0065; SpiderMonkey shell: js var tru\u0065; typein:1: SyntaxError: missing variable name: typein:1: var tru\u0065; typein:1: ^ It looks like Carakan (Opera), JSC and V8 allow this. I can't test IE. 2) Within the constraints of 1) decide what we actually want to specify. Do we want console.log(fals\u0065) to print false or undefined? Carakan, JSC and V8 alert undefined. Anyone have IE results? Looks like SpiderMonkey implemented ES5 not ES3, probably accidentally and ahead of time. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Terminology: “non-method function”
We use `Function.prototype.partial` in our codebase. We consider `Function.prototype.papply` but thought that would be too confusing with `Function.prototype.apply`. From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Axel Rauschmayer [a...@rauschma.de] Sent: Wednesday, April 11, 2012 12:54 To: Allen Wirfs-Brock Cc: es-discuss Subject: Re: Terminology: “non-method function” Great idea. Do we need similar this-less variants for call and apply? Probably not, the former is just a normal function call. The latter can by handled by the spread operator. IIRC, what one actually does here is not currying, but partial application. However, I don’t see any good method name being derived from “partial application”. On Apr 11, 2012, at 18:44 , Allen Wirfs-Brock wrote: On Apr 11, 2012, at 7:12 AM, Peter van der Zee wrote: On Wed, Apr 11, 2012 at 1:01 AM, Axel Rauschmayer a...@rauschma.demailto:a...@rauschma.de wrote: What is a good term for functions that don’t have/use dynamic `this`? A bound function? I'm leaning in that direction. A bound function has an unbound (dynamic) this while a bound function has a bound (fixed) this. To further clarify this it might be useful to better differentiate binding this from currying the arguments. We might do this by adding a new Function.prototype.curry function that doesn't have a this value as its first argument. You would then fn.curry(1,2) If you want to create a curried function from fn with 1 and 2 as the first two fn arguments. and: fn.bind(foo) if you want to created a bound version of fn where this is bound to the value of foo. The semantics of fn.bind(foo,1,2) could then be explained as being equivalent to fn.bind(foo).curry(1,2) Allen -- Dr. Axel Rauschmayer a...@rauschma.demailto:a...@rauschma.de home: rauschma.dehttp://rauschma.de twitter: twitter.com/rauschmahttp://twitter.com/rauschma blog: 2ality.comhttp://2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Extra functions on Arrays, Maps, etc..
On Apr 7, 2012, at 20:37, Rick Waldron waldron.r...@gmail.commailto:waldron.r...@gmail.com wrote: On Sat, Apr 7, 2012 at 8:31 PM, Erik Arvidsson erik.arvids...@gmail.commailto:erik.arvids...@gmail.com wrote: On Sat, Apr 7, 2012 at 17:28, Rick Waldron waldron.r...@gmail.commailto:waldron.r...@gmail.com wrote: As in, its [[Class]] is Array and Array.isArray( nodes ) would evaluate to true? No, it means that Object.getPrototypeOf(NodeList.prototype) === Array.prototype. Yes, this part was clear in the links you sent. The question I had was about two things that were not addressed in the links (that I could see, please correct if I missed them) There will be much confusion on the web if Array.isArray(nodes) returns false, while nodes.push( node ), nodes.slice( 0, 2 ) just work, especially during periods of transition from DOMx to DOM4. Rick Fortunately all the Array.prototype methods are generic so it all just works. -- erik I think the benefits are so great I'm happy to deal with any confusion. Although, it sounds like I'll be wanting to go back to `instanceof Array`, which is kind of funny. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Do Maximally Minimal classes carry their weight?
As a quick follow-up:
Perhaps adding non-arcane-incantation private name declarations would be enough
to push maximally-minimal classes from “nice, but are they worth it?” to “this
gives us something we can’t get anywhere else.” To wit:
class Set extends Collection {
private setContents, setTally
constructor(initialSize = 2) {
this.{
@setContents: new Array(initialSize),
@setTally: 0
}
}
// ...
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: March 28 meeting notes
Great to gain consensus indeed. This looks just about as nice as it can be.
Minor question: There are no examples of very empty arrow functions, e.g.
`=` or `= 5`. And from what I can tell reading the grammar , they are not
allowed. Is this necessary? CoffeeScript's allowance of `- (expr)` gives some
nice-looking code, for example see [1].
Bigger question: It sounds like TCP was sacrificed in favor of maximal
minimalism, which makes sense. But, is this strawman friendly toward future TCP
endeavors, perhaps in ES.next.next? For example, if `do` expressions were
specced in the way discussed previously, could putting one to the right of the
= result in TCP semantics?
[1]: https://github.com/domenic/sinon-chai/blob/master/test/callOrder.coffee
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Brendan Eich
Sent: Thursday, March 29, 2012 02:30
To: Waldemar Horwat
Cc: es-discuss
Subject: Re: March 28 meeting notes
Waldemar Horwat wrote:
Consensus on:
- Have only one arrow, namely =
- this is always static. No provision for dynamic this.
- Other than the treatment of this, the function behaves like a normal
function. return, break, etc. behave as though the function body were
in a function(...){...}.
To be discussed later:
The thing that comes after the arrow:
1. Always an expression (possibly a do expression)?
2. A block if it starts with {, otherwise an expression.
See
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax -- I'm a
bit tired from travel so may have made a mistake or two, and I know some of the
examples should be better. Comments welcome.
Great to gain consensus on this today!
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Finding a safety syntax for classes
On Mar 27, 2012, at 13:10, David Herman dher...@mozilla.com wrote:
I recognize the C.prototype.constructor idiom already exists, but it's a weak
idiom. I'm not crazy about the idea of strengthening a problematic but
currently unreliable and rarely used idiom.
Dave
Speaking as a dev, I would like this idiom to be stronger (i.e. be there by
default in a classy world). One use case that immediately springs to mind is
try { } catch (e) { switch(e.constructor) { } }, which we've used a couple
times in the absence of Mozilla-style exception guards.
Your concern about possibly not wanting to expose the constructor makes a lot
of sense, but perhaps we could leave .prototype.constructor configurable and
let people in such a situation explicitly delete it.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: RegExps in array functions
Does passing /foo/i.test not work? (Away from computer.) Perhaps it should, if
it doesn't?
On Mar 23, 2012, at 16:28, Felix Böhm
esdisc...@feedic.commailto:esdisc...@feedic.com wrote:
Hi guys,
just a first try for a proposal: Array.prototype.[filter/some/every] currently
require a function as an argument. Most of the time, everything I want to do is
check if they match a certain pattern. So what I end up writing is a RegExp
that matches the pattern, and calling its test() method for every member of the
array.
My proposal is to allow people to use a regular expression as an argument for
the three methods. Current implementations throw an error when they don't get a
function as an argument, so this won't break any (working) code.
An example:
[fOo,bAr].filter(function(elem){ return /foo/i.test(elem); });
should be replaceable with
[fOo,bAr].filter(/foo/i);
For non-string members of the array, the current behavior of the
RegExp.prototype.test method (ie. converting the value to a string) applies.
Any reasons why this is a bad idea? (Or is it just my bad attitude? :D )
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: RegExps in array functions
Would it be a reasonable language upgrade to pre-bind test? I imagine there
would be philosophical objections, but would be interested in hearing them
enunciated. (Are there other pre-bound methods in ES5's standard library?)
On Mar 23, 2012, at 21:48, Russell Leggett
russell.legg...@gmail.commailto:russell.legg...@gmail.com wrote:
On Mar 23, 2012, at 9:05 PM, John Tamplin
j...@google.commailto:j...@google.com wrote:
On Fri, Mar 23, 2012 at 8:21 PM, Domenic Denicola
dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote:
Does passing /foo/i.test not work? (Away from computer.) Perhaps it should, if
it doesn't?
It does, if you bind it to the regex first. Ie:
var re = /foo/i;
var filtered = array.filter(re.test.bind(re));
So that doesn't look better than just passing an anonymous function wrapper
(though you probably want to build the regex once).
Yeah, gotta watch your receiver. If you find yourself doing this a lot, just
make a function. You can either add a method to RegExp that returns a bound
version of test, or make a function that takes a regex and returns a bound
version of test like
function predicate(regex){
return regex.test.bind(regex);
}
var filtered = array.filter(predicate(/foo/i));
- Russ
--
John A. Tamplin
Software Engineer (GWT), Google
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: simpler, sweeter syntax for modules
Callable modules are a hugely important use case. jQuery and Underscore spring
to mind. I’ve made one myself [1].
Also important: what about construct-able modules? Or to put it another way,
what about exporting a module that is a class? Examples from Node [2] [3] and
Node-land [4] [5] are abundant.
It makes me think a more generic mechanism would be required to export any
arbitrary object as the module itself. Perhaps
export module as function jQuery(selector, context) { … }
// or
function jQuery(selector, context) { … }
export module as jQuery;
export module as class Runnable { … }
// or
class Runnable { … }
export module as Runnable;
[1]: https://github.com/domenic/dict/blob/master/dict.js
[2]: https://github.com/joyent/node/blob/master/lib/stream.js
[3]: https://github.com/joyent/node/blob/master/lib/module.js
[4]: https://github.com/visionmedia/mocha/blob/master/lib/runnable.js
[5]: https://github.com/visionmedia/mocha/blob/master/lib/suite.js
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Andreas Rossberg
Sent: Thursday, March 22, 2012 07:55
To: es-discuss
Subject: Re: simpler, sweeter syntax for modules
One point that I haven't seen mentioned yet (and it is unrelated to syntax):
export call makes me cringe -- making modules callable is not just weird, it
seems completely future-hostile to the possibility of having parameterized
modules. I don't think it is worth bending the notion of module like that if
all that is gained is minor convenience.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Using Object Literals as Classes
Just to contribute to this... er... fun-thread...
My team uses the closure pattern for our classes (i.e. no prototype methods
at all), since we value encapsulation. I can't imagine we're alone.
So any class solution that doesn't fully incorporate private names (e.g. by
making them awkward via manual Name.create(), etc.) will leave that audience
behind, still using closures and ignoring any new class sugar.
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Russell Leggett [russell.legg...@gmail.com]
Sent: Friday, March 16, 2012 17:07
To: Kevin Smith
Cc: es-discuss
Subject: Re: Using Object Literals as Classes
On Fri, Mar 16, 2012 at 4:26 PM, Kevin Smith
khs4...@gmail.commailto:khs4...@gmail.com wrote:
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:
http://wiki.ecmascript.org/doku.php?id=harmony:object_extension_literal_class_pattern
provides a worse user experience than what I already have. The goal post for
any class syntax or idiom is not this:
function Blah()
Blah.prototype = Object.create(BaseClass.prototype);
Blah.prototype.a = function() {};
Blah.prototype.b = function() {};
It is rather this:
var MyClass = new Class({
extends: BaseClass,
a: function() {},
b: function() {}
});
And in the post I conclude fairly early on that the object extension literal
class pattern described above does not meet or exceed this goal post, not by a
long shot.
+1, agreed, not by a long shot
Now, if object literal extensions were such that I could use them in a class
library (any class library), then that would be fine. But as indicated in the
post, they cannot. The full advantages to be derived from object literal
extensions with respect to class construction are *unbreakably bound* to the |
operator.
As such | does not fill in missing low-level pieces of the puzzle, so much as
dictate how higher level abstractions must be built. I cannot build a higher
level class abstraction from fundamentals without leaking the implementation of
that abstraction.
The answer cannot be that I ought not build higher level abstractions.
If the answer is that we'll have a class syntax, then great. But then we have
to ask the related question, should super et. all defined on the object
literal level? And do we even need special | or .{} syntax, then?
Again, thanks David for reading and replying. I have great respect for
everyone's ideas, and I'm just trying to fully explore this one.
I am also a library author, and *yes* I've also created yet another class
abstraction (seemed like a good idea at the time, 5 years ago) and I have to
say, I totally agree. As much as I want to take advantage of |, its just not
good enough at the high or the low level. Because it has to take a literal on
the RHS, it can't be used inside a class abstraction library, and because its
still so imperative, its not very good at the high level.
I think the people that will really be able to take advantage of this will be
language designers that target JS. CoffeeScript could probably put this to good
use.
- Russ
kevin
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: usable enough private names (was: Re: Using Object Literals as Classes)
Yes, this looks pretty solid, although I can't remember seeing it anywhere.
(Sorry for the top-posting; my webmail doesn't want to add the 's for me so I
figured this is better than the alternative.)
From: Herby Vojčík [he...@mailbox.sk]
Sent: Friday, March 16, 2012 17:20
To: Domenic Denicola
Cc: Russell Leggett; Kevin Smith; es-discuss
Subject: usable enough private names (was: Re: Using Object Literals as Classes)
Domenic Denicola wrote:
Just to contribute to this... er... fun-thread...
My team uses the closure pattern for our classes (i.e. no prototype
methods at all), since we value encapsulation. I can't imagine we're alone.
So any class solution that doesn't fully incorporate private names (e.g.
by making them awkward via manual Name.create(), etc.) will leave that
audience behind, still using closures and ignoring any new class sugar.
Is the current (the last winning alternative afaicr) state good enough
for you?
In a few words:
private x,y;
will be desugared to
const x = Name.create(), y = Name.create();
So you would need to write your code as:
module ... {
...
private foo, bar;
...
class Alpha {
... uses names foo, bar in constructor and methods
}
... maybe use the same name in subsequent classes and functions
}
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Using Object Literals as Classes
On Mar 16, 2012, at 18:05, David Bruant bruan...@gmail.commailto:bruan...@gmail.com wrote: Le 16/03/2012 23:00, Rick Waldron a écrit : On Fri, Mar 16, 2012 at 5:12 PM, Domenic Denicola dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote: Just to contribute to this... er... fun-thread... My team uses the closure pattern for our classes (i.e. no prototype methods at all), since we value encapsulation. I can't imagine we're alone. For my own curiosity, can you point me to some examples where you are strategically avoiding the use of the prototype pattern? When he needs actual encapsulation. Unfortunately, methods on prototype require to have properties that are public. If you avoid prototype methods, all your attributes and private methods can be shared by public method scopes. David Exactly. I am away from computer right now, so I cannot dig up examples from our codebase at work, but essentially we use the pattern described by Crockford in http://www.crockford.com/javascript/private.html And we use only privileged methods (on the instance), not public ones (on the prototype). This also neatly avoids binding problems via a single `var that = this` at the top of the constructor. Here is an example from some of my own open-source code: https://github.com/domenic/pubit/blob/master/lib/Publisher.js (The `var that = this` in that particular example is unnecessary since no public methods call each other; it's just there as part of the boilerplate encapsulated-class pattern I always use.) Hope this helps, despite being cobbled together on an iPhone. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Using Object Literals as Classes
On Mar 16, 2012, at 18:12, Rick Waldron waldron.r...@gmail.commailto:waldron.r...@gmail.com wrote: On Fri, Mar 16, 2012 at 6:04 PM, David Bruant bruan...@gmail.commailto:bruan...@gmail.com wrote: Le 16/03/2012 23:00, Rick Waldron a écrit : On Fri, Mar 16, 2012 at 5:12 PM, Domenic Denicola dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote: Just to contribute to this... er... fun-thread... My team uses the closure pattern for our classes (i.e. no prototype methods at all), since we value encapsulation. I can't imagine we're alone. For my own curiosity, can you point me to some examples where you are strategically avoiding the use of the prototype pattern? When he needs actual encapsulation. Unfortunately, methods on prototype require to have properties that are public. If you avoid prototype methods, all your attributes and private methods can be shared by public method scopes. Sorry, I don't subscribe to this as an adequate argument against prototypes. jQuery has a whole lot of hidden, private functions and data - using an IIFE. Ultimately, the developer makes the decision to write well encapsulated code - prototype or closure pattern should have no bearing. Rick David That only works for singleton modules, not multi-instance classes. WeakMaps and private names both provide solutions for associating private data to an instance, without abandoning prototypes, but that brings me back to my original point: class sugar must make such association easier than manual `Name.create()` usage, on par with the ease of the closure pattern. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Using Object Literals as Classes
From: Rick Waldron [mailto:waldron.r...@gmail.com]
Sent: Friday, March 16, 2012 18:40
To: Domenic Denicola
Cc: David Bruant; es-discuss
Subject: Re: Using Object Literals as Classes
On Fri, Mar 16, 2012 at 6:20 PM, Domenic Denicola
dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote:
On Mar 16, 2012, at 18:12, Rick Waldron
waldron.r...@gmail.commailto:waldron.r...@gmail.com wrote:
On Fri, Mar 16, 2012 at 6:04 PM, David Bruant
bruan...@gmail.commailto:bruan...@gmail.com wrote:
Le 16/03/2012 23:00, Rick Waldron a écrit :
On Fri, Mar 16, 2012 at 5:12 PM, Domenic Denicola
dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote:
Just to contribute to this... er... fun-thread...
My team uses the closure pattern for our classes (i.e. no prototype methods
at all), since we value encapsulation. I can't imagine we're alone.
For my own curiosity, can you point me to some examples where you are
strategically avoiding the use of the prototype pattern?
When he needs actual encapsulation.
Unfortunately, methods on prototype require to have properties that are public.
If you avoid prototype methods, all your attributes and private methods can be
shared by public method scopes.
Sorry, I don't subscribe to this as an adequate argument against prototypes.
jQuery has a whole lot of hidden, private functions and data - using an IIFE.
Ultimately, the developer makes the decision to write well encapsulated code -
prototype or closure pattern should have no bearing.
Rick
David
That only works for singleton modules, not multi-instance classes.
Multi-instance as in many instances created from a class? Every call to
jQuery or its alias $ actually produces a new, unique object instance from a
real constructor.
The example you gave produces a constructor that wraps a handful of instance
method definitions along with several function declarations - which I'm arguing
could just as easily be outside of that function declaration, but inside of an
IIFE.
There are two issues here:
1) “Private methods” could be moved outside to the module level (IIFE level if
you wish).
This is true, but would necessitate passing the private state into these
methods: `callListener` would need `options`, which then propagates to an extra
parameter on `callListenersForSync` and `callListenersForAsync`. Obviously this
problem multiplies as you add more private state to the object, eventually
ending up passing around a “secrets” object containing all your private state,
which is a bundle of joy to program against. /sarcasm
2) “Public methods” cannot be moved outside to the prototype level.
If instead of `that.publish = function () { ... }` inside the constructor, I
had `Publisher.prototype.publish = function () { ... }` outside the
constructor, then the function body could not access the “private instance
variables” `normalListeners` and `oneTimeListeners`, or the constructor
parameter `options`.
The only way to allow a `Publisher.prototype.publish` method to access this
per-instance state would be to un-encapsulate it, making it public so that they
could be accessed as e.g. `this._normalListeners`.
This is what I mean when I say I eschew the prototypal pattern in favor of the
closure pattern. All of my methods are instance methods, because they need
access to private, encapsulated state.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Using Object Literals as Classes
From: Axel Rauschmayer [mailto:a...@rauschma.de]
Sent: Friday, March 16, 2012 18:35
To: Domenic Denicola
Cc: Russell Leggett; Kevin Smith; es-discuss
Subject: Re: Using Object Literals as Classes
Just to contribute to this... er... fun-thread...
My team uses the closure pattern for our classes (i.e. no prototype methods
at all), since we value encapsulation. I can't imagine we're alone.
Do you see privacy via closures and prototypes as mutually exclusive? In my
experience, they work well in combination. Do you add all of your methods to
the instance? That would have the advantage of making it easier to access
private data from public methods, but would consume more memory.
In theory I see them as complementary, but in practice I have never been able
to integrate prototypes. Consider: a method can only be attached to a prototype
if it needs access to an instance’s public state only, and not to its private
state. These cases are extremely rare. And when they do occur, I usually ask
myself—is this really an instance-level method? Why not make it a module-level
method that operates on instances of my class?
We have so far made the trade-off of sacrificing memory for encapsulation.
(Although, I still find it strange that modern JITers don’t pull out of the
code of the method to reuse in each instance, and instead duplicate it every
time. Cf. the “Joining” section of [1].) It hasn’t bitten us yet.
[1]: http://wiki.ecmascript.org/doku.php?id=strawman:const_functions
So any class solution that doesn't fully incorporate private names (e.g. by
making them awkward via manual Name.create(), etc.) will leave that audience
behind, still using closures and ignoring any new class sugar.
True. Something along the lines of:
class C {
private {
age, strength
}
/* syntactic sugar for
module name from @name;
var age = name.create();
var strength = name.create();
*/
// private method
@incAge() {
this.@agemailto:this.@age++;
}
}
This does look familiar, and quite useful. But it’s certainly outside the scope
of “object literals as classes,” which I think ties to my original point in
supporting the OP that object literals alone are not sufficient.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Using Object Literals as Classes
From: Rick Waldron [mailto:waldron.r...@gmail.com]
Sent: Friday, March 16, 2012 19:28
To: Domenic Denicola
Cc: David Bruant; es-discuss
Subject: Re: Using Object Literals as Classes
On Mar 16, 2012, at 7:11 PM, Domenic Denicola
dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote:
From: Rick Waldron
[mailto:waldron.r...@gmail.com]mailto:[mailto:waldron.r...@gmail.com]
Sent: Friday, March 16, 2012 18:40
To: Domenic Denicola
Cc: David Bruant; es-discuss
Subject: Re: Using Object Literals as Classes
On Fri, Mar 16, 2012 at 6:20 PM, Domenic Denicola
dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote:
On Mar 16, 2012, at 18:12, Rick Waldron
waldron.r...@gmail.commailto:waldron.r...@gmail.com wrote:
On Fri, Mar 16, 2012 at 6:04 PM, David Bruant
bruan...@gmail.commailto:bruan...@gmail.com wrote:
Le 16/03/2012 23:00, Rick Waldron a écrit :
On Fri, Mar 16, 2012 at 5:12 PM, Domenic Denicola
dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote:
Just to contribute to this... er... fun-thread...
My team uses the closure pattern for our classes (i.e. no prototype methods
at all), since we value encapsulation. I can't imagine we're alone.
For my own curiosity, can you point me to some examples where you are
strategically avoiding the use of the prototype pattern?
When he needs actual encapsulation.
Unfortunately, methods on prototype require to have properties that are public.
If you avoid prototype methods, all your attributes and private methods can be
shared by public method scopes.
Sorry, I don't subscribe to this as an adequate argument against prototypes.
jQuery has a whole lot of hidden, private functions and data - using an IIFE.
Ultimately, the developer makes the decision to write well encapsulated code -
prototype or closure pattern should have no bearing.
Rick
David
That only works for singleton modules, not multi-instance classes.
Multi-instance as in many instances created from a class? Every call to
jQuery or its alias $ actually produces a new, unique object instance from a
real constructor.
The example you gave produces a constructor that wraps a handful of instance
method definitions along with several function declarations - which I'm arguing
could just as easily be outside of that function declaration, but inside of an
IIFE.
There are two issues here:
1) “Private methods” could be moved outside to the module level (IIFE level if
you wish).
This is true, but would necessitate passing the private state into these
methods: `callListener` would need `options`, which then propagates to an extra
parameter on `callListenersForSync` and `callListenersForAsync`. Obviously this
problem multiplies as you add more private state to the object, eventually
ending up passing around a “secrets” object containing all your private state,
which is a bundle of joy to program against. /sarcasm
There is more then one way to skin a goose...
2) “Public methods” cannot be moved outside to the prototype level.
I should've used a period, or perhaps a whole new paragraph, because I never
meant to imply that they could or should.
If instead of `that.publish = function () { ... }` inside the constructor, I
had `Publisher.prototype.publish = function () { ... }` outside the
constructor, then the function body could not access the “private instance
variables” `normalListeners` and `oneTimeListeners`, or the constructor
parameter `options`.
Inside the IIFE, WeakMap (or shimmed equivalent) with instance as key, pointing
to an object with all of those goodies stored in it.
The only way to allow a `Publisher.prototype.publish` method to access this
per-instance state would be to un-encapsulate it, making it public so that they
could be accessed as e.g. `this._normalListeners`.
See WeakMap strategy above
This is what I mean when I say I eschew the prototypal pattern in favor of the
closure pattern. All of my methods are instance methods, because they need
access to private, encapsulated state.
I still say that this can all be accomplished with prototypes and IIFEs.
I agree, it can all be done with WeakMaps or private names combined with
modules and IIFEs, as I pointed out a few emails back and as Tab points out in
another reply. But at that point (especially with WeakMaps, but also with
unsugared private names) I am jumping through enough hoops that I’d rather just
go the closure route.
In my opinion, if ES6 delivers no sugar for private names, very few
closure-pattern-using developers will jump through the necessary hoops to
convert from closures to prototypes. (They’d also have to deal with losing the
guaranteed `that = this` binding, but that’s another story.) That’s really the
only point I wanted to make in this thread; I think we got sidetracked talking
past each other about implementation patterns in current ES5/ES5-plus-WeakMaps
environments.
___
es
RE: optional function keyword
This wins on so many levels:
* Short but C-like myList.map((x) x*x) syntax for the most common cases, where
TCP doesn't matter.
* Full TCP support via an entirely new, but still pretty C-like, syntax with
myList.map((x) do { … }).
* The two are sufficiently close to each other and to the existing syntax to
be recognizable as functions, but sufficiently different to convey new
semantics.
The earlier Prototype 1.6 example:
inGroupsOf(number, fillWith) {
fillWith = Object.isUndefined(fillWith) ? null : fillWith;
return this.eachSlice(number, (slice) do {
while(slice.length number) slice.push(fillWith);
slice;
});
},
inject(memo, iterator, context) {
iterator = iterator.bind(context);
this.each((value, index) do {
memo = iterator(memo, value, index);
});
return memo;
},
invoke(method) {
var args = $A(arguments).slice(1);
return this.map((value) value[method](...args));
},
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of David Herman
Sent: Tuesday, March 06, 2012 17:58
To: Brendan Eich
Cc: es-discuss
Subject: Re: optional function keyword
On Mar 6, 2012, at 2:56 PM, Brendan Eich wrote:
David Herman wrote:
Moreover, if you wanted to do some control along with an expression, you could
use do-expressions:
myList.map((x) do { for (...) { ... } f(x) })
Note that combination (expression closures + do-expressions) brings back the
exact same expressiveness of block-lambda.
Not so, because no TCP. Only block-lambdas preserve TCP fully.
Says you! :)
To be clear: what I'm suggesting is that expression closures would *not* be
syntactic sugar for statement bodies, but rather would be TCP-respecting. Most
of the time this wouldn't even be noticeable, until you use do-expressions.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: How about replacing | with -
If we’re taking votes: -1. I would actively avoid using this in my own ES6 code, because of the unnecessary confusion it would cause to those coming from CoffeeScript. From: Carlos Prado García Sent: Saturday, March 03, 2012 17:58:38 To: es-discuss Subject: Re: How about replacing | with - +1 for - syntax. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: set.delete method name
I appreciate the feedback, but I do not understand the rationale. The rationale I found compelling from upthread was that remove is a more apt antonym to add. To compare, delete's natural counterpart would be put. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Typeof this in getters (was: eval on non-strings)
Both IE10 Developer Preview (10.0.8102.0) and IE10 Platform Preview 4 (10.0.8103.0) output number object objectobject We'll see if tomorrow's drop does any better. Sounds like I should file test262 bugs as well. From: Mark S. Miller [mailto:erig...@google.com] Sent: Tuesday, February 28, 2012 14:38 To: Domenic Denicola Cc: Allen Wirfs-Brock; Brendan Eich; es-discuss@mozilla.org Subject: Re: Typeof this in getters (was: eval on non-strings) I like the output display on http://jsfiddle.net/CxdMs/16/ a bit better. I just tried it on very recent versions of 4 or the 5 major browsers. I was shocked to see that all of them were wrong. Correct would be number number object object Chrome 19 gave number number object number Opera 12, Safari WebKit 5.1.3 (7534.53.10, r109097), and Mozilla FF Nightly 13 all gave number object object object What does the latest IE10 preview do? Domenic, as you post bugs against the browsers, please send me the URLs. Thanks. On Tue, Feb 28, 2012 at 10:03 AM, Domenic Denicola dome...@domenicdenicola.com wrote: Specifically regarding ToObject. It's use is important in minimizing the semantic differences between primitive values and Objects. In ES5 we eliminated the automatic wrapping of primitive values used as this values in method invocations. That means that in most cases 42 and (new Number(42)) can be used interchangeably. If we start leaving out ToObject calls in random places the distinction between a primitive value and a wrapped primitive values will start tripping people up. This actually is apropos of something I'd been meaning to ask about. Consider the following JSFiddle: http://jsfiddle.net/CxdMs/15/ It seems reasonably clear that the result for functions should be object (non-strict)/number (strict), according to section 10.4.3. But for getters, the major browsers disagree, and my spec-fu can't find anything besides the abovementioned section. Firefox and IE9 say object/object, while V8 says number/number. And at least one version of JavaScriptCore we have lying around says number/object. If someone could walk me through the spec correctly, I'd be happy to file appropriate browser bugs. Note that this is a real-world issue. The Chai.js assertion library is trying to break free of V8 and become useful in browsers, but is encountering problems due to this behavior: https://github.com/logicalparadox/chai/issues/32 Thanks all, Domenic ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Typeof this in getters (was: eval on non-strings)
To clarify, the expected results here are:
Non-strict
Typeof this inside a function when called on a number: object
Typeof this inside an Object.prototype getter when used on a number: object
Strict
Typeof this inside a function when called on a number: number
Typeof this inside an Object.prototype getter when used on a number: number
right?
Yes.
There’s over a hundred test cases that have already been created, and will be
contributed ‘soon’ to cover https://bugs.ecmascript.org/show_bug.cgi?id=180.
One such test case is:
function foo()
{
'use strict';
return typeof(this);
}
function bar()
{
return typeof(this);
}
return foo.call(1) === 'number' bar.call(1) === 'object';
Chrome fails this one with `bar.call(1)==='number'`, but everyone else passes.
Another that seem relevant here is:
function testcase() {
var o = {};
Object.defineProperty(o, foo, { get: function() { use strict; return
this; } });
return o.foo===o;
}
This is irrelevant because it is not testing primitives and boxing. (More
formally, it is not testing the relevant part of 10.4.3 that we are discussing.)
On that note, is there anything that’s particularly interesting spec-wise in
defining foo on Object.prototype instead of a generic object and validating
there?
It's relevant because it allows use on numbers, i.e. `(0).getMe`. The same
results happen if you define on `Number.prototype`.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Array.prototype.contains
Perhaps using indexOfIdentical from
http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Erik Arvidsson [erik.arvids...@gmail.com]
Sent: Thursday, February 23, 2012 15:15
To: es-discuss@mozilla.org
Subject: Array.prototype.contains
DOM4 added a new interface called DOMStringList for the sole reason
that Array does not have contains. Before this the return type was an
Array of Strings so we could use indexOf, map, forEach etc. Now that
it is using a non Array we lost all of that.
Proposal: Add Array.prototype.contains, implemented as:
Object.defineProperty(Array.prototype, 'contains', {
value: function(value) {
return this.indexOf(value) !== -1;
},
enumerable: false,
configurable: true,
writable: true
}{);
This is trivial enough to do in user code but since DOM4 depends on it
we should just put it in the right place; In ES6.
--
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Set iterators
As a starting point, would it make sense to provide an API that matches Array.prototype methods (where applicable)? I think this ties in to my earlier desire to make Array.prototype methods work with iterators in general [1]. That is, I think the correct way to do this would be: 1) To specify that set is an iterator that, when iterated over, returns its values. 2) To specify that all iterators get (at least): every, filter, forEach, map, reduce, reduceRight, some One potential sticking point is that we might want filter and map to return sets themselves. [1]: https://mail.mozilla.org/pipermail/es-discuss/2012-February/020356.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: __proto__ security
I am generally with Brendan that specifying __proto__ is not very necessary. But, one thing I would like enshrined in the spec is that `__proto__ in Object.create(null) === false`. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: lexical for-in/for-of loose end
This seems like a highly compelling argument. I hope I'm not the only one who thinks the existing behavior of `for(;;)` makes sense. Granted, that comes from understanding the detail that closures close over variables and not values, which most users will not. But in general, `for(;;)` makes it very clear that there's a single mutating variable, which the desugarings proposed here seem to overcomplicate and contradict. As exemplified by the comments to Eric's blog post, the current behavior is not very astonishing to many developers, and once it's explained once, becomes intuitive. (Yes, sampling bias, but still.) The question is whether saving that pedagogic burden is worthwhile. I argue that it isn't. `for(;;)` is a low-level construct even in ES5, where `Array.prototype.forEach` supplants it for the most part. It doesn't have to do what I mean; it should do what I say. Introducing an extra set of curly braces around the loop so that my `let` loop variables don't get hoisted to the outer scope is the most work that makes sense to me. -Domenic -Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Andy Wingo Sent: Tuesday, February 07, 2012 5:15 To: es-discuss@mozilla.org Subject: Re: lexical for-in/for-of loose end Hi Allen, On Mon, 2012-02-06 at 11:08 -0800, Allen Wirfs-Brock wrote: We're putting a lot of energy into trying to figure out how to fix for(let;;) when it probably shouldn't even be the preferred form of numeric looping going forward. If we can make for-in/for-of attractive enough then it is less clear why we need to fix for(;;) [...] Maybe don't even add let/const forms to for(;;). Just as food for thought, here's a C# designer on why they decided to leave for (int i=0; iN; i++) alone, when they decided to make for (int i in L) bind a fresh i: We have this same problem in for blocks, but for blocks are much looser about what the loop variable is; there can be more than one variable declared in the for loop header, it can be incremented in odd ways, and it seems implausible that people would consider each iteration of the for loop to contain a fresh crop of variables. When you say for(int i; i 10; i += 1) it seems dead obvious that the i += 1 means increment the loop variable and that there is one loop variable for the whole loop, not a new fresh variable i every time through! We certainly would not make this proposed change apply to for loops. http://blogs.msdn.com/b/ericlippert/archive/2009/11/12/closing-over-the-loop-variable-considered-harmful.aspx Regards, Andy ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Array extras functionality for iterators
ES5's existing array extras make working with arrays a joy. However, sometimes arrays are not the right tool for the job. Perhaps you want lazy evaluation semantics (generators). Or perhaps you want to communicate that the list is immutable (compare .NET's `IEnumerableT` or Java's `IterableT`). ES Harmony seems to have the answer: iterators! Like `IEnumerableT` or `IterableT`, they are the most basic primitive of iteration. Yay! But, if my `fetchAllProducts()` method returns an iterator, I don't get my array extras. Sad. --- This may be solvable in library-space, but the iterator proposal doesn't seem to have an Iterator.prototype I could extend. So we end up with unfortunate underscore-style wrappers: _(iterator).chain().map(mapper).some(predicate).value() _.some(_.map(iterator, mapper), predicate) I propose adding the array extras to any iterator (in some way), such that we can have syntax similar to the following: iterator.map(mapper).some(predicate) // returns an iterator The methods I would like to see are: * every, filter, forEach, map, reduce, reduceRight, some * Optionally: join, toString * Controversially: sorted, reversed (non-mutating versions of sort and reverse) What do you think? -Domenic ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Array extras functionality for iterators
I'd say every and other methods like that should take another argument that specifies the number if times to test. This seems reasonable. Preferably that parameter would be optional, since the majority of the time my iterators will not be derived from infinite generators (and I know this). Otherwise I'd just keep passing `Infinity` as the third argument to my methods. Is it possible to detect infinite generators ahead of time? My intuition says no. map and filter clearly would be very useful. I'm not sure about the others. Losing the others would be a shame. As I mentioned, much of the time I want to expose something with the semantics of an iterator, even if internally to my module or class I am storing the data as an array. So even if infinite generators cause problems for implementing `every` et al., the vast majority of real-world iterators would not be derived from infinite generators. Thus my above desire for the extra argument being optional. Currently in our codebase, we have a number of these methods (like `fetchAllProducts()`) that return `slice()`ed copies of internal arrays, since we don't want to expose the arrays directly. (Iterators would of course be the best solution here.) Over the course of 77K LOC, the only methods we don't use on the products collection are `join`, `reduceRight`, `reverse`, and `toString`. And we do use `join` on some of the simpler collections (`fetchProductTags()`). So they're all useful! -Domenic On Sat, Feb 4, 2012 at 10:06 PM, Michael A. Smith mich...@smith-li.com wrote: Sorry for the resend. Meant to include the list. I like this idea a lot! However, what would be the correct behavior of a method like 'every' on an infinite generator? -Michael A. Smith On Fri, Feb 3, 2012 at 3:54 PM, Domenic Denicola dome...@domenicdenicola.com wrote: ES5's existing array extras make working with arrays a joy. However, sometimes arrays are not the right tool for the job. Perhaps you want lazy evaluation semantics (generators). Or perhaps you want to communicate that the list is immutable (compare .NET's `IEnumerableT` or Java's `IterableT`). ES Harmony seems to have the answer: iterators! Like `IEnumerableT` or `IterableT`, they are the most basic primitive of iteration. Yay! But, if my `fetchAllProducts()` method returns an iterator, I don't get my array extras. Sad. --- This may be solvable in library-space, but the iterator proposal doesn't seem to have an Iterator.prototype I could extend. So we end up with unfortunate underscore-style wrappers: _(iterator).chain().map(mapper).some(predicate).value() _.some(_.map(iterator, mapper), predicate) I propose adding the array extras to any iterator (in some way), such that we can have syntax similar to the following: iterator.map(mapper).some(predicate) // returns an iterator The methods I would like to see are: * every, filter, forEach, map, reduce, reduceRight, some * Optionally: join, toString * Controversially: sorted, reversed (non-mutating versions of sort and reverse) What do you think? -Domenic ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Array extras functionality for iterators
someVeryLargeArray.iMap(someFunction); // Lazy, guaranteed only to be iterable How about `someVeryLargeArray.asIterator().map(someFunction)`? -Domenic ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
