Hi David,
[A propos of nothing, can I ask that you either change your font or use
plain-text email? Your font shows up almost unreadably small in my mail client.]
I'm currently working on the WeakMap documentation [1] and I have thought of
two points:
1) myWeakMap.set(key, value) doesn't
I've been concerned about the schedule risk of classes for ES.next; following
are some thoughts about a minimal class feature that I believe satisfies the
most important needs while leaving room for future growth.
I think the bare-minimum requirements of classes would be:
- declarative class
- providing idiomatic syntax for calling the superclass constructor
But what about subclass method calling superclass method(s)?
In terms of priorities, I think super-constructors are the single most
important use case for super. But I think super-methods fall out naturally from
the
Yeah, tough questions. I don't know. I tried to make the API flexible by
allowing custom builders, and in fact if you look at the test suite you'll see
I did a proof-of-concept showing how you could generate the format that Mark
mentioned:
Thanks-- missed one when manually doing s/ImportPath/ImportBinding/g. Fixed.
Thanks,
Dave
On Jul 1, 2011, at 9:55 AM, Kam Kasravi wrote:
Should this
ImportDeclaration(load) ::= import ImportBinding(load) (,
ImportBinding(load))* ;
ImportPath(load) ::= ImportSpecifierSet from
the AST API strawman - given the positive discussions on this list, I
thought the idea was implicitly accepted last year, modulo details,
so I was surprised not to see a refined strawman promoted.
It hasn't really been championed so far. I was concentrating on other proposals
for ES.next.
2011/7/6 Andreas Rossberg rossb...@google.com
While putting together some test cases for Object.keys, I wondered: is
it intended that property names are always passed to traps as strings?
That is indeed the intent.
Unless they are private name objects, right?
Dave
I'm not sure. I briefly checked the private names proposal
http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects and I
think the detailed interaction with proxies still has to be fleshed out.
Sure, I'll be happy to work with you on this.
The proposal does mention: All
, Brendan Eich wrote:
On Jul 8, 2011, at 7:17 AM, David Herman wrote:
The proposal does mention: All reflective operations that produce a
property name, when reflecting on a private name, produce the name’s
.public property instead of the name itself.
Would the same hold for reflective
And just to be clear, I meant produce in the sense of producer/consumer
relationship on the trap functions, not in the generative sense.
Dave
On Jul 8, 2011, at 8:40 AM, David Herman wrote:
Sorry, yes. Too early in the morning for me. :)
Indeed, handler traps are exactly the place where
I think I still haven't fully grokked what | means on array literals, but
could it also be used to subclass Array? For example:
function SubArray() {
return SubArray.prototype | [];
}
SubArray.prototype = new Array;
I'm not sure what Array.prototype methods would or
So from this viewpoint (and regarding that example with squares), it's good
to have also `Array.seq(from, to)` method (the name is taken from Erlang, I
just frequently uses lists:seq(from, to) there):
bikeshedArray.range seems like an intuitive name as well./bikeshed
Array.seq(1,
I mentioned two benefits I can see to Array.of over []-literals here:
https://twitter.com/#!/littlecalculist/status/89854372405723136
1) With Array.of you know you aren't going to accidentally create holes, and
2) if you're passing it to a higher-order function you know you aren't going to
I'm not sure what Array.prototype methods would or wouldn't work on
instances of SubArray.
All of them. They are all generic.
We're speaking too broadly here. It depends on what we want to work how. For
example, .map can't magically know how to produce a SubArray as its result if
that's
Agreed. I think that's a pretty common way people think about null vs
undefined, and it's consistent with the language's behavior.
Dave
On Jul 10, 2011, at 3:09 PM, liorean wrote:
On 10 July 2011 22:23, David Herman dher...@mozilla.com wrote:
Another common and useful fusion of two
According to the module grammar, the following is valid:
691module car {
function startCar() {}
module engine {
function start() {}
}
export {start:startCar} from engine;
}
It seems like there would be issues with exporting module elements after the
module has been
My point is that the map spec is a deterministic algorithm because
side-effects would be noticeable otherwise. However, this prevent
implementations where function calls would be done in parallel for instance
(for better performances). In some cases (like the one I showed), the exact
, at 8:11 PM, David Herman dher...@mozilla.com wrote:
According to the module grammar, the following is valid:
691module car {
function startCar() {}
module engine {
function start() {}
}
export {start:startCar} from engine;
}
It seems like there would be issues
Adding a non-enumerable Array.prototype method seems doable to me, if the
name is clear and not commonly used.
We can probably still add Array.prototoype.isArray if that would help to
establish the pattern. Document as being preferred over Array.isArray
This doesn't make sense to me.
I'm not so sure about this now. I was just reviewing with Dave how the design
evolved. We had Function.isGenerator, analogous to Array.isArray. For taskjs,
Dave had thought he had a use-case where the code has a function and wants to
know whether it's a generator. It turned out (IIUC) that
My understanding of generators was naively that they are syntactic sugar for
defining an iterator.
Well, I think I understand what you're getting at: there's a sense in which
generators don't add the ability to do something that's *absolutely impossible*
to express in ES5.
OTOH, generators
Putting private properties on a proxy or storing it in a weak map are simple
protocols you can use to keep track of proxies that you know about. You can
hide or expose this information then without however many or few clients you
like. If you want to give people access to knowledge about your
Hi Luke,
The idea is definitely to subsume typed arrays as completely as possible.
* Array types of fixed length
The current design fixes the length of an ArrayType instance as part of the
ArrayType definition, instead of as a parameter to the resulting constructor.
I'm not sure I
I've been exploring private name objects [1] and I'm a bit confused by a few
things in the proposal, especially the Reflection example...
The page was out of date, sorry. I've updated the page to reflect the agreement
we came to in the last face-to-face, which was that private names should
Understood WRT the forgeability of strings -- I was more concerned with the
potential hazard of toStringing the values of an own-names array, only to
find out you have several keys with the string value undefined. Sure you're
doing it wrong, but string keys are an es5 invariant -- it's
Yep. Sorry, editing snafu -- I'd started to call it a non-issue when it
occurred to me that proxy authors would still have to know not to string
coerce keys. No big deal -- proxy authors should know better than to rely on
es5 invariants.
Agreed.
Throw at the point where a unique name
Mozilla has evalInSandbox built-ins. We've talked about them, but no one has
produced a strawman based on this work. The module loader API:
http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders
provides enough functionality.
In fact, I think sandbox is a pretty good intuition for
!)
/be
On Sep 2, 2011, at 3:33 PM, David Herman wrote:
Object.getPropertyDescriptor
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
, not dismissive.)
Wasn’t it David Herman a while ago who listed a minimal feature list? For me
it would be:
1. Super property references (mainly methods)
2. Super constructor references
3. Subclassing (mainly wiring the prototypes)
4. Defining a class as compactly as possible (with subclassing
A couple reactions:
- strings are already interned in current engines for symbol-like performance;
there's no need to introduce symbols into the language
- private names are overkill for most uses of enums; just use string literals
- in SpiderMonkey I think you get better performance if your
Fixed, thanks.
Dave, digging his way out of a massive backlog...
On Sep 23, 2011, at 12:18 PM, Axel Rauschmayer wrote:
http://wiki.ecmascript.org/doku.php?id=harmony:string_extras
I’ve found a small bug:
String.prototype.endsWith = function(s) {
var t = String(s);
return
On this particular issue, I'm inclined to agree -- I think we should be
extremely sparing with how many new sigils, if any, we introduce into the
language. You'll notice Brendan has repeatedly said similar things about | and
.{ for example. Syntax matters.
But I feel like now might be a good
I mostly have a similar approach in mind for tail calls. Precise about the
interface, imprecise/informative about the implementation requirements. For
WeakMaps, that means a well-defined API with informal English describing the
expectations about memory consumption. For tail calls, it means a
I don't think we can get away with repurposing _ as a pattern sigil, since it's
already a valid identifier and used by popular libraries:
http://documentcloud.github.com/underscore/
In my strawman for pattern matching, I used * as the don't-care pattern:
I have some thoughts about how to use Narcissus as a basis for a compiler to
ES3 as well. It's obviously not necessary to do separately from Traceur, but it
might be interesting to experiment with alternative implementation strategies.
I haven't really done anything in earnest yet, including
,
but not vice versa.
Dave
On Oct 11, 2011, at 8:00 PM, John J Barton wrote:
On Tue, Oct 11, 2011 at 6:17 PM, David Herman dher...@mozilla.com wrote:
Traceur is very good! I'd just like to have something that compiles to ES5
without intermediate libraries, the way CoffeeScript works, so that it's
If you want to create a clean-slate proxy object -- for example, a dictionary
-- then you can't predefine toString or valueOf. But this means your object
will always fail at the semantic operations [[ToString]] and [[ToPrimitive]].
For example:
var obj = Proxy.create(myEmptyHandler,
TypeError: can't convert obj to primitive type
Dave
On Oct 16, 2011, at 1:46 PM, David Herman wrote:
If you want to create a clean-slate proxy object -- for example, a dictionary
-- then you can't predefine toString or valueOf. But this means your object
will always fail at the semantic
Forgive me that I've not kept track of where we are in the discussion about the
additional receiver argument.
I think I just found a pretty important use case for the receiver argument. Say
you want to keep some information about a proxy object in a Map or a WeakMap,
and you want the handler
D'oh -- of course, you're right. The use case I'm describing wants the proxy,
not the receiver.
Thanks,
Dave
On Oct 16, 2011, at 2:44 PM, David Bruant wrote:
Le 16/10/2011 23:02, David Herman a écrit :
Forgive me that I've not kept track of where we are in the discussion about
message I sent this afternoon.
(Well, that and performance, which quite possibly sucks. So this may not be a
viable idea. It was an interesting experiment, anyway.)
Dave
On Oct 16, 2011, at 2:49 PM, David Bruant wrote:
Le 16/10/2011 23:02, David Herman a écrit :
Forgive me that I've not kept track
If you want to stratify toString/valueOf in general and for all objects, I
would very much support that.
I'm not sure I understand what you mean. Do you mean something like:
js var obj = Object.create(null, {});
js String(obj)
TypeError: can't convert obj to string
js
I agree with Andreas. The implicitly-called base level methods are not
meta-methods or (spec language) internal methods. They do not need their
own traps. They are base-level property accesses.
Well, certainly that's the way the language currently works. But the way it
currently works is
Hi Tom, this looks very promising. Some comments below; quoting the wiki page
inline.
* target is the object which the direct proxy wraps
Just checking: presumably this proposal doesn't allow for target to be a
primitive, right? (Other than the special case of null you mention later.)
I.e.,
(Dave Herman has another way to say this: [ ] and . can be viewed as
operating on two separate property name spaces, but for legacy/normal ES
objects those namespaces are collapsed into a single shared namespace.)
Lest the above be construed as a tacit approval on my part... ;)
IMHO the
I do not yet fully understand the rationale behind dicts.
Nothing fancy, really. Just an idiomatic way to create a non-polluted
string-to-value map. In ES5 you can use Object.create(null), which is not bad
but still kind of a hack. Wouldn't it be nice to have sweet literal syntax for
a
a certain aesthetic that says that's icky, but JS makes it so
convenient that it's the obvious thing to do.
Dave
On Oct 17, 2011, at 4:15 PM, Allen Wirfs-Brock wrote:
On Oct 17, 2011, at 3:34 PM, David Herman wrote:
IMHO the single property name space of es-current is a feature, not a bug
There are other alternatives, such as supporting both alternatives with two
different entry points (con: API proliferation), taking an optional boolean
flag indicating to return the pair (con: too dynamic a type), taking an
optional outparam object (con: what is this? C?). OK, so most of those
We could even allow for direct proxies to acquire non-standard internal
properties from their target object. This could be a useful principle when
wrapping host objects.
This seems important in order to make host methods work, e.g., the ones that
access the [[Value]] property. I guess
These are all good points. I'm not sure (1) is worth bringing back in all the
we won't let you say things you can't enforce complexity, but (2) is maybe
non-obvious enough not to be worth it. I'm backing off my please make it null
position now. :) It actually seems pretty reasonable just to
[1] http://wiki.ecmascript.org/doku.php?id=strawman:dicts [D.H. already
mentioned that this proposal does not reflect his current thinking, so beware]
FWIW, I don't really know what my current thinking is. :)
Dave
___
es-discuss mailing list
You can disagree with anything if you're allowed to change the terms of the
discussion. :)
Brendan said JS is run-to-completion, which means that if you call a function
and control returns to you, no intervening threads of control have executed in
the meantime. But then you changed his example
Hi Kris,
Your proposal has a lot of similarities to
http://wiki.ecmascript.org/doku.php?id=strawman:deferred_functions
which was proposed this past spring.
I'm not sure I follow what's top-down vs bottom-up about the two different
approaches. Let me suggest some terminology that has
Hi Jeremy,
Thanks for the proposal. I've been advocating a minimalist approach to classes
for a while now; I think it's a good goal. A few of us sketched out something
similar on a whiteboard in the last face-to-face meeting; at least, it used the
object literal body. We hadn't thought of two
class Fox extends Animal {
dig: function() {}
}
Fox becomes a constructor function with a `.prototype` that is set to an
instance of Animal that has been constructed without calling the Animal()
constructor. (The usual temporary-constructor-to-hold-a-prototype two step
shuffle). All
But IIUC, you're proposing a semantics where you construct a brand new object
P whose __proto__ is SuperClass.prototype and then copy all the
own-properties of the RHS into P.
Not quite. P is a constructor function (class object), SuperClass is a
constructor function. Unless I'm
I think one piece of this is worth reiterating: As long as JS.next classes
are mostly sugar for prototypes, and prototypes aren't going to be deprecated
or removed in the next version of JavaScript (two propositions that I think
most of us can get behind) ... then it's very important that
I think we probably have an interesting question for Dave and Sam about how
to support version evolution of modules. Is there a module equivalent of
monkey patching. What if we have an implementation that exposes a V1 module
(particularly a built-in module) and code that depends upon upon
, David Herman dher...@mozilla.com wrote:
ES6 modules are not extensible, for a number of reasons including
compile-time variable checking. But of course API evolution is critical, and
it works; it just works differently. Monkey-patching says let the polyfill
add the module exports by mutation
This is the only one I've seen that seems like it should work, but it depends
on whether SES/Caja/etc have some sort of way of neutering __proto__. Just from
hacking around, I don't see much way of censoring it in SpiderMonkey.
MarkM, do you have any tricks for censoring __proto__?
Dave
On
Perhaps __proto__ should not be writeable in use strict?
That's a great idea! This never occurred to me, and I have not heard anyone
suggest this. Thanks!
Doesn't work.
obj[(function(__){return __ + proto + __})(__)]
Dave
___
es-discuss
Still there, but write it out fully, to compare to the cited text:
import keys from @iter;
for (i of keys(o)) {
body
}
Unless we default-import a standard prelude,
I think we should.
this is a bit much compared to add own as a modifier after for in for/in (not
for/of)
Let's answer this once we have the module-ized version of the standard library.
Which I've been promising for far too long (mea culpa). Will get started on
this tonight.
Dave
On Nov 8, 2011, at 9:04 PM, Brendan Eich wrote:
On Nov 8, 2011, at 8:39 PM, David Herman wrote:
Instead of taking
On Nov 9, 2011, at 1:33 PM, Quildreen Motta wrote:
On 09/11/11 19:20, Brendan Eich wrote:
And if you need to break out of forEach, just, umm, don't use forEach. It's
the wrong tool for the job.
Clearly people like the forEach array extra in conjunction with Object.keys.
With
Brendan and Dave mention explicit semicolon. Yes, it's seems so by the
grammar (though, have to check more precisely), but it can be acceptable
price.
It's a serious price, though. Today if I write:
if (q) { ... }
else { ... }
(f())
then ASI kicks in after the else body. If we
On Nov 11, 2011, at 3:48 AM, François REMY wrote:
I think you strongly underestimate the distinction problem. ... It's
completelty unclear to me. If there's no way to tell what the return
statement of the block is, there's no way to implement your proposal.
It's actually quite easy to
On Nov 11, 2011, at 8:19 AM, Mark S. Miller wrote:
On Fri, Nov 11, 2011 at 7:40 AM, gaz Heyes gazhe...@gmail.com wrote:
On 11 November 2011 15:33, Mark S. Miller erig...@google.com wrote:
let a = ({
print('doing stuff');
100;
});
How do you know the difference between a blank block
On Nov 11, 2011, at 9:50 AM, Allen Wirfs-Brock wrote:
do-expression is a very good solution
Why thank you! ;-)
How gorgeous is that?
not very...
but if I see any of:
let a = do {...
let a = {|| ...
let a = { ...
I immediately know what follows. That is gorgeous...
I'm not
How gorgeous is that?
It's normal and consistent with other blocks, I'd say.
Sorry, that was an (American?) English colloquialism -- a rhetorical question
meaning that's gorgeous!
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
On Nov 11, 2011, at 10:50 AM, Erik Arvidsson wrote:
We've all looked at jQuery code and envied the conciseness of its chaining
APIs. Most of us also looked at it and thought; Yuk, making everything a
method of jQuery and always return the jQuery object is ugly.
Beauty is in the eye of the
I would translate How X is that? as that is very X! :)
Dave
On Nov 11, 2011, at 12:26 PM, Dmitry Soshnikov wrote:
On 11.11.2011 23:44, David Herman wrote:
How gorgeous is that?
It's normal and consistent with other blocks, I'd say.
Sorry, that was an (American?) English colloquialism
Late to the party, but I've brought more booze.
On Nov 5, 2011, at 2:41 PM, Brendan Eich wrote:
We have:
1. Should an array pattern always query 'length'?
2. If the answer to (1) is no, then should ... in an array pattern query
'length'?
On reflection and at this point in the thread,
On Nov 11, 2011, at 2:51 PM, Mike Samuel wrote:
If statements as expressions goes forward, we should look into
tweaking completion values.
IMHO, a code maintainer who sees
resource = ..., foo(resource)
would expect to be able to wrap the use of resource in a try finally thus
On Nov 11, 2011, at 3:36 PM, Allen Wirfs-Brock wrote:
On Nov 11, 2011, at 3:17 PM, David Herman wrote:
A pattern of the form
[a0, a1, 〰〰, ak, ...r]
desugars to
a0 = %v[0];
a1 = %v[1];
〰〰
ak = %v[k];
let %length = %v.length;
do we sample the length here
On Nov 11, 2011, at 4:23 PM, Axel Rauschmayer wrote:
It would be nice if r was optional:
[..., b0, b1, b2] = arr
Agreed. Pure win, no downside.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Nov 11, 2011, at 4:18 PM, Rick Waldron wrote:
Dave, if nesting were out of the question and monocle-mustache operator
always looked like an object literal as they currently exist, would it still
be as vile? With that form, I'm a big fan.
I'm of multiple minds (a condition I'm gradually
On Nov 11, 2011, at 5:31 PM, Axel Rauschmayer wrote:
Also: we'll definitely want to allow it for splicing, so the grammar will
have to allow it already, and symmetry/consistency argue for allowing it in
destructuring too. Likewise for function formals and actuals.
Using it for splicing
On Nov 16, 2011, at 12:11 PM, Dmitry Soshnikov wrote:
Yes, I understand, but it doesn't answer the question -- why do we need
_additional_ keyword
Infix operators can be conditional keywords. That's the current plan for is,
IINM.
Dave
___
|
On Nov 16, 2011, at 11:27 PM, Mark S. Miller wrote:
On Wed, Nov 16, 2011 at 11:24 PM, David Herman dher...@mozilla.com wrote:
Someone who shall remain nameless shot this down when I floated it privately.
But I just have to throw this out there, because I kind of can't stop myself
On Nov 16, 2011, at 11:28 PM, Dmitry Soshnikov wrote:
However, we nevertheless had/have the semantics for `with', and it may cause
confusion.
Right, that's the natural objection. But... with-statements are dead, long live
with-expressions!
Moreover, you need to specify that [noNewLineHere]
On Nov 16, 2011, at 11:27 PM, Mark S. Miller wrote:
On Wed, Nov 16, 2011 at 11:24 PM, David Herman dher...@mozilla.com wrote:
obj with { foo: 12 } with { bar: 13 } with { baz: 17 }
I don't get it yet. What do you mean by dynamically extending prototype
chains? What does the above
On Nov 17, 2011, at 3:53 AM, Dmitry Soshnikov wrote:
Once again, it's absolutely the same approach which I showed yesterday with
using `extends'
(https://mail.mozilla.org/pipermail/es-discuss/2011-November/018478.html).
My point has absolutely nothing to do with semantics and everything to
On Nov 17, 2011, at 12:10 AM, Russell Leggett wrote:
since in this example I only used the object literal variant. (The function,
array, etc variants do things that Object.create can't do.)
I think this is ultimately the downfall of 'with' as a complete replacement
for | or extends. It
On Nov 17, 2011, at 3:17 AM, Axel Rauschmayer wrote:
obj with { foo: 12 } with { bar: 13 } with { baz: 17 }
I like the idea! As it is syntactically different in this role, errors should
be easy to spot.
But I think `with` “points in the wrong direction” (object `obj` *with*
On Nov 17, 2011, at 5:13 AM, Russell Leggett wrote:
Look closer - it is being used as a prefix operator, not an infix operator.
extends Proto {...}
There have been a few alternatives discussed in the previous thread. IMO, in
each one of them, `extends` is awkward. The one you're talking
On Nov 17, 2011, at 5:16 AM, Dmitry Soshnikov wrote:
And `extends` fails completely as the syntax.
This is why it's so wide-spread in other languages for inheritance, right? ;)
In other languages it's not a stand-alone operator but a part of class syntax.
(I don't know Ruby, so maybe you'll
On Nov 17, 2011, at 5:37 AM, Axel Rauschmayer wrote:
[cc-ing es-discuss again]
On Nov 17, 2011, at 14:20 , Russell Leggett wrote:
If | changed to allow non-literal RHS values, I could see it getting more
use
obj | comparable | enumerable | {...}
but right now, that has a big
On Nov 17, 2011, at 6:20 AM, Axel Rauschmayer wrote:
I'm not sure what the semantics of this would be. Are you inventing
multiple-prototype inheritance? That's not going to happen.
Single inheritance, a prototype chain composed from the given objects, in the
given order. An infix
On Nov 17, 2011, at 6:26 AM, Mike Samuel wrote:
2011/11/17 David Herman dher...@mozilla.com:
obj with { foo: 12 } with { bar: 13 } with { baz: 17 }
Does the below fit your syntax and isn't it lexically ambiguous with
the old with?
obj
with ({ foo: 12 })
{}
This was discussed above
On Nov 17, 2011, at 8:00 AM, Jason Orendorff wrote:
On Wed, Nov 16, 2011 at 1:12 PM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
One thing that all of these discussions are missing is the hoisting
property of function and any possible future classes. If we use let
Point = ... we lose all
On Nov 17, 2011, at 6:41 AM, Dmitry Soshnikov wrote:
And uses `.extend' instance method (inherited from Object) for imperative
delegation-based mixing.
Sure, so that's just a method then, not an `extends` keyword.
OK, though, I'd like again to notice Scala:
object foo extends bar {
On Nov 17, 2011, at 12:56 PM, Brendan Eich wrote:
This would require migration through two steps. One to ES5 strict to get rid
of the with above (which relies on ASI). The second to ES.next or whatever
retasks 'with'.
I don't understand this-- that's already the case, since there's no
On Nov 17, 2011, at 10:17 AM, Jason Orendorff wrote:
I'm with Allen. If ES classes can contain any initialization code, I
think it should run in program order, interleaved with top-level
statements. Anything else is just confusing.
This is a great point, which I'd overlooked (not sure if
On Nov 17, 2011, at 1:30 PM, Brendan Eich wrote:
If I have code of the kind Mike Samuel showed:
obj
with ({ foo: 12 })
{}
and I migrate directly into ES-whatever with 'with' as you propose (instead
of |), then I do not get an early error.
Understood.
Also, using 'with' around object
On Nov 17, 2011, at 2:08 PM, David Herman wrote:
On Nov 17, 2011, at 1:30 PM, Brendan Eich wrote:
If I have code of the kind Mike Samuel showed:
obj
with ({ foo: 12 })
{}
and I migrate directly into ES-whatever with 'with' as you propose (instead
of |), then I do not get an early
We intend to have a synchronous API for accessing the built-in modules (those
beginning with @ in their URL), as well as a synchronous way to access
modules that have already been loaded. This went by briefly in July:
https://mail.mozilla.org/pipermail/es-discuss/2011-July/015929.html
I'm
On Nov 17, 2011, at 3:48 PM, Roozbeh Pournader wrote:
On Thu, Nov 17, 2011 at 3:08 PM, Roozbeh Pournader rooz...@google.com wrote:
That would make something like this the minimum code needed to use the
module:
var g11n;
Object.system.load(@g11n, function (g11n_module) {
g11n =
On Nov 17, 2011, at 5:20 PM, Rick Waldron wrote:
On Thu, Nov 17, 2011 at 7:40 PM, Waldemar Horwat walde...@google.com wrote:
Array.from(a) is superfluous because it's expressed even simpler as
[... a]. DaveH withdrew it.
Perhaps Array.from() was either misunderstood or miscommunicated. I
On Nov 19, 2011, at 5:50 PM, Brendan Eich wrote:
On Nov 19, 2011, at 2:20 PM, Rick Waldron wrote:
Q. We don't use option parameter like that in JS (see previous point for
actual example)
Using an object-as-option parameter is a very common API design pattern in
real-world JavaScript
On Nov 20, 2011, at 2:24 PM, Brendan Eich wrote:
On Nov 20, 2011, at 11:16 AM, Allen Wirfs-Brock wrote:
Actually, I think you would want to say:
function frob(arg1, arg2, {foo = defFoo, bar = defBar, baz = defBaz}={}) {
Thanks.
It may be that for destructuring, in general, we
201 - 300 of 654 matches
Mail list logo
