On Thu, Oct 9, 2014 at 4:57 PM, John Lenz concavel...@gmail.com wrote:
or a simple utility method
Promise.reject could be used.
```js
asyncFunc()
.then(count = count = 0 ? count : Promise.reject(new Error(...)))
.then(...)
.catch(...)
```
Nathan
On Mon, Sep 22, 2014 at 3:30 PM, Benjamin Grurnbaum ing...@gmail.com wrote:
With libraries like Knockout utilizing 'with', I'm not sure it'll go away
anytime soon.
Adding monocle mustache to a future ES might help with getting rid of it. ;)
Nathan
An `isnt` operator has been proposed before[1].
Parens are ugly. Proto[2] supports negating operators with `!` (`foo !in
bar`, `foo !is bar`, `foo !like bar`).
[1] http://wiki.ecmascript.org/doku.php?id=harmony:egal
[2] https://github.com/Nathan-Wall/proto
On Mon, Aug 25, 2014 at 6:40 AM
Out of mere curiosity, why is it desired that `symbol + ''` throw?
Nathan
On Tue, Aug 12, 2014 at 10:39 PM, Erik Arvidsson erik.arvids...@gmail.com
wrote:
symbol + '' must continue to throw.
I was suggesting that String(symbol) should not throw.
This can be spec'ed as String( value )
I have a syntax proposal, but it goes along with a slightly different way of
thinking of this.
The proposed bind operator[1] can take a function which acts as a method and
make a call to it with a specific receiver without the receiver needing to have
the method defined as a property (basically
(Sorry about the formatting in the last one. Trying again.)
I have a syntax proposal, but it goes along with a slightly different way of
thinking of this.
The proposed bind operator[1] can take a function which acts as a method and
make a call to it with a specific receiver without the
Hi Giacomo,
Not sure whether this will be of interest to you, but I have been working on a
JS-derived language called Proto (still highly experimental) which has a switch
statement that works exactly as you described:
https://github.com/Nathan-Wall/proto/blob/master/docs/control/switch.md
`hasOwn` has been deprecated recently.
Why no `hasOwn`?
Nathan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Finalized spec or finalized implementations?
A lot of things are already being implemented (with varying levels of
conformance, of course) in latest versions of engines (from browsers to
node) — http://kangax.github.io/es5-compat-table/es6/
--
kangax
Yes, thanks, I'm aware of
Hey guys, I really think you're all doing an awesome job with the development
of the future of the language, especially all the work Allen's putting into the
drafts. I'm really dying to start using some of these features.
Last I heard (probably over a year ago), the plan was to have ES6 out by
Claude Pache wrote:
`Math.sign` is expected to represent the mathematical sign
function, which has a precise definition, see [1], [2].
Please note that `+0` and `-0` are the same value as far as
maths is concerned, and that value is neither positive nor
negative. (Or both nonnegative and
Nathan Wall wrote:
At the very least, I think Oliver has a point in that it'd be very
useful to have a sign function which would return 1 for +0 and -1
for -0. I've needed this in the past. If it shouldn't be `Math.sign`,
perhaps there should be a `Number.sign` which would match the other
use
Before getting into the exact situation with `Object.create` and functions, the
first thing to understand is that `Object.create(proto)` creates an object with
prototype of `proto`. As others have said, this is different from cloning.
Here's a simple example which should show the differences
I asked about this several months back[1]. There is a bug filed
https://bugs.ecmascript.org/show_bug.cgi?id=1114
Nathan
[1] https://mail.mozilla.org/pipermail/es-discuss/2012-December/027372.html
From: oli...@apple.com
Subject: Iteration of the
+1
Nathan
Domenic Denicola wrote:
A well-known problem with loops, as implemented in various programming
languages, is that infinite loops are silenced by default. Consider the
following program, which simply adds some numbers in a loop:
```js
var sum = 0;
while (Math.random()
Allen Wirfs-Brock wrote:
Actually, this is a good point. As currently specified Object.assign
of with an own __proto__ property on the RHS object will trigger a
[[SetPrototypeOf]] on the LHS object. Is that what we want. It is a
direct fallout of specifying Object.assign as the equivalent of
In reading Rick's response, I noticed my comments were rather messy
themselves. Correcting for clarity.
Given that `__proto__` is defined as an accessor on `Object.prototype`,
I think this should be expected. Any other setter defined on the object
or its prototype chain will be invoked in
Rick Waldron wrote:
If this were how it was defined, I would say get rid of it and
practitioners will carry on using their own non-nanny implementations.
If it can't invoke setters then it loses properties like innerHTML.
eg.
Object.assign(div, {
innerHTML: `${name}BR`,
id: an-id,
The name `@@toStringTag` sounds like a function, like `toString` and `toFixed`,
but it's just a string property. The fact that `@@toPrimitive` is a function
further makes the point.
Has just `@@stringTag` been considered?
Nathan
Domenic Denicola wrote:
It's toString tag, not to StringTag.
Ah, you know, I hadn't made that connection. That's interesting.
I still think I would prefer something else... maybe even just `@@tag`. But
that certainly makes more sense out of the naming.
Thanks!
Nathan
Allen Wirfs-Brock wrote:
Nathan Wall wrote:
Set foo to bar.[[Baz]]
Does `foo` ever result in a non-undefined value if `bar` doesn't have
an own `[[Baz]]` property but inherits from an object that has an
internal `[[Baz]]` property?
I couldn't say, as this notation is never used
Allen Wirfs-Brock wrote:
Internal implies this is not an property.;
Allen
Ok, thanks for clearing that up!
Nathan
___
es-discuss mailing list
es-discuss@mozilla.org
This should be a quick answer; I'm just looking for clarity. Are there any
situations where internal data properties may be inherited? For example:
Set foo to bar.[[Baz]]
Does `foo` ever result in a non-undefined value if `bar` doesn't have an own
`[[Baz]]` property but inherits from an
Brendan Eich wrote:
Nathan Wall mailto:nathan.w...@live.com
October 7, 2013 8:05 PM
This should be a quick answer; I'm just looking for clarity. Are
there any situations where internal data properties may be inherited?
For example:
Set foo to bar.[[Baz]]
Does `foo` ever result in a non
I'm wondering what the best syntax is for object destructuring outside of a var
declaration. For instance, the following works in Firefox Nightly and Traceur:
var { a, b } = foo;
but the following doesn't:
var a, b;{ a, b } = foo;
I presume this is because in the second case the { a,
In no case does anyone that I've spoken to, on TC39 or anywhere else
around this planet, want *yet another* bottom type and singleton value a
la null and undefined. No one. Those who speak Spanish and nearby
languages tend to say ¡Basta! -- I'm not kidding :-|.
Except those in favor of nil?
Hi, I do not know if this is the correct list to discuss these things. If it is
not, please redirect me.
I have done some work on implementing the AP2 draft I could find here
http://github.com/domenic/promises-unwrapping and I have a few potential bugs
to report. If this is not the latest
Note that this turns the common use case on its head. The creator of the
promise passes the resolver to the outside party and holds onto the promise
itself. That's why it's been helpful two full objects with different roles.
Nathan
Nathan Wall wrote:
Domenica Denicola wrote:
Since
Reading through [the meeting notes][1]:
YK: You don't need unique symbols when you can just expose private symbols.
+1. I've been wondering this for a long time but thought that there was too
much consensus around unique symbols to question it. I'm glad these questions
are being asked. I
Why do arrow functions require a parameter list and a body? That is, none of
the following are allowed:
- `= foo`
- `bar =`
- `=`
Instead you need the more-verbose
- `() = foo`
- `bar = {}`
- `() = {}`
Any chance of relaxing this a bit?
+1
Erik Arvidsson wrote:
This can either be done by exposing an object that has the same
interface as Date. This could throw on set or it could skip the set
methods entirely. If you want instanceof to work then all the methods
needs to be overridden.
Overriding the methods on a real date object
Domenic Denicola wrote:
I believe exposing `[[DateValue]]` as a (non-private) symbol-keyed property
would do the trick, since `Object.freeze` seems to set all property keys to
non-writable/non-configurable.
This seems like it would be a backward-compatible change. But it's so simple
I
Allen Wirfs-Brock wrote:
Nathan Wall wrote:
Last time I asked, `Object.freeze` friends don't affect existing symbol
properties on an object (though new ones can't be added). I think this is
pretty important. Has this changed?
Object.freeze and friends affect all properties in the same way
See this thread:
https://mail.mozilla.org/pipermail/es-discuss/2013-May/030551.html
On Fri, Jun 21, 2013 at 11:34 PM, BelleveInvis infinte.c...@hotmail.comwrote:
The current behaviour of __proto__ looks ugly. The better way might be
make __proto__ an unconfigurable accessor of
Do you think we can come to some sort of agreement, as discussed below,
that [[ProtoSetter]] doesn't need to be realm restricted. Such an
agreement would let us write the simplest possible specification of
__proto__.
Very timely question. I've discussed this within the other Cajadores
Brendan Eich wrote:
... https://mail.mozilla.org/pipermail/es-discuss/2013-February/028631.html
It looks like the setter throws only if called on an object from a
different realm, so maybe it will work for your intended uses. It
won't work cross-frame, in other words.
/be
Great! Will the
I didn't get a direct response to my question about mutating proto on objects
which don't inherit from Object.prototype, but I'm inferring from [1] that it
won't be possible. I find this unfortunate, but I realize this issue has seen
a lot of discussion in the past and there are reasons for
A previous thread [1] brought to my attention the fact that objects which don't
inherit from Object.prototype won't have mutable __proto__. This was something
I had missed and breaks some scripts I'm currently using because I have objects
which I don't want to inherit from Object.prototype but
David Bruant wrote:
Tom Van Cutsem wrote:
To my mind, the blame for the breakage lies with `Object.prototype`
being mutated by the third-party script, not with property descriptors
inheriting from Object.prototype. Thus, a fix for the breakage should
address that directly, rather than
Given that `defineProperty` uses properties on the prototype of the
descriptor[1] and `getOwnPropertyDescriptor` returns an object which inherits
from `Object.prototype`, the following use-case is volatile:
function copy(from, to) {
for (let name of Object.getOwnPropertyNames(from))
(1) Nuke the special properties (`get`, `set`, and `value` when any of them
is not defined) on a descriptor returned by `getOwnPropertyDescriptor` which
shouldn't be inherited through the descriptor's prototype. By nuke them, I
mean specify that they be defined as `undefined`, much like
Would it be possible to make / what are the thoughts on making `length` mutable
on functions?
Writing to `length` could be a useful functionality for library code. For
instance, implementing something like `bind` correctly requires the arity of
the bound function to be the same as the original
Allen Wirfs-Brock wrote:
I think I previously asked if anybody is aware of situations where
Object.isFrozen tests are done but Object.freeze is not used to set
objects to the frozen state. So far, no answers. Anybody?
Speaking just from my own experience as a user of ES5, I have not found
David Bruant wrote:
...
Security is very loaded with emotions of people afraid to have their
password stolen and cyber attacks. It's also loaded with the notion of
human safety and human integrity which, as human beings are sensitive to.
Maybe I should start using a different word...
Great
Claus Reinke wrote:
Careful there, you're not done!-) With nodejs, adding the following
var table = makeTable();
table.add(1);
table.add(2);
table.add(3);
var secret;
Object.defineProperty(Array.prototype,42,{get:function(){ secret = this;}});
table.get(42);
console.log(secret);
-brock.com
Date: Wed, 13 Feb 2013 17:49:27 -0700
CC: claus.rei...@talk21.com; e-t...@ecma-international.org;
es-discuss@mozilla.org
To: nathan.w...@live.com
On Feb 11, 2013, at 7:13 PM, Nathan Wall wrote:
Thank you for this explanation. This is very interesting! If you don't
mind, I have some
Thank you for this explanation. This is very interesting! If you don't mind,
I have some questions/concerns I'd like to clear up. (In particular I want to
make sure I understand; I don't intend to argue for one side or the other ATM,
but this change may require me to refactor some old code
David Bruant wrote: David Bruant wrote:
Garbage collectors have evolved and cycles aren't an issue any longer, weak
references or not. Kevin Gadd wrote:
Cycles are absolutely an issue, specifically because JS applications
can interact with systems that are not wholly managed by the
Kevin Smith wrote:
In ES5, there is no distinction between public and private data within
an object. If you want to create private data, you must do so using a
closure. All private data is therefore external to the object in
question. The data does not follow the object around. This is a
In this light, it may also make sense to make Function.prototype.@@create and
Function.prototype.@@hasInstance non-writable, non-configurable.
Regardless of the defaults, SES could presumably defend itself in the
same same way.
If you make Function.prototype.@@create non-writable,
Sure - and approaches like this (or simpler - people are clever!) can
be factored away into a neat library, without having to mess with the
underlying object model.
ES6 provides WeakMaps and Proxies. Why not see what people do with
those before introducing private slots?
Is it really
These use cases can be made dynamic be some kind of
Proxy.fromNowOnForwardUnknownPrivateSymbols(proxy, false);
API. This is not truly dynamic. I'd say no truly dynamic use cases
exist, where you must decide _at_the_exact_point_of_access_. IMO.
I would be ok with something more along the
set(key, value) {
let data = this[$data];
if (!data)
throw new TypeError('this object must be a StringMap');
if (!(key in data))
this[$size]++;
data[key] = value;
}
Doh! I wrote that in such a way that an inconsistency cannot be introduced,
since
Consider again the mixin scenario. A user wants to create a class with
private methods:
let privateMethod = new Symbol(true);
class C {
constructor() {}
[privateMethod]() { }
publicMethod() { this[privateMethod](); }
}
And then use that class as a mixin:
class D {
In order to satisfy security guarantees, properties which are keys on
private symbols are not returned by getOwnPropertyNames.
That's why the methods are bound to the original object.
I realize, however, that non-method properties don't work correctly this way
(so I probably just should
Regardless of the this binding, the privately keyed method will not
be copied over from the source object and hence will be undefined when
called.
I think you're not understanding. Here's a simpler example that runs in modern
ES engines:
var A = {
foo: function() {
Allen Wirfs-Brock wrote:
if we excluded the cascade result at the API design level then we are
making it impossible for those who like the cascade pattern from using it.
The biggest thing I got out of the discussion Mark linked to is that the
cascade pattern is potentially supportable with an
Nathan wrote:
Hey Tom, I think you missed my point. The point was that in David and Boris'
discussion they agreed that the DOM should throw if it is given a Proxy in
`appendChild`. That sounded to me like it presumed that the DOM had a magical
ability to distinguish between DOM objects and
Thank you for the thoughtful reply. You sufficiently answered many of my
concerns related to DOM, but I want to focus on the need for the
`unknownPrivateSymbol` trap.
David Bruant wrote:
Imagine the following scenario:
Untrusted code A is given access to a graph of objects through a
hmm.. I just realized that B doesn't have direct access to O. So even if B does
have access to M, trying to get N from P[M] would expose N to the membrane.
So perhaps I don't understand your original dilemma?
(Forgive me if I'm making you repeat past discussions for my sake. It's not my
David Bruant wrote:
Yes and once the membrane has captured N, it has to search again if some
object use in A---B communication has an N property... and restart all
over if an object does and has another private name attached.
Theoretically, the membrane can always be one step ahead of the
I'm still reluctant to give up on the unknownPrivateSymbol trap, because
doing so means giving up on mediation for one case.
In this case, we were able to capture every single private symbol passed
back and forth, but in another situation, maybe we didn't create A and B.
Someone else created
Choosing symbols or a weakmap would make a huge difference in how proxy
replacement would react to DOM algorithms.
If the DOM in terms of accessing private properties, then proxies can
replace DOM objects transparently. Their unknownPrivateSymbol trap
will be called [2] and if they don't
Brendan Eich wrote:
Nathan Wall wrote:
In the case of (2), the implementation using a private symbol will fail on
a call to `setTime` when the object is frozen (I think).
Nope, we agreed that frozen objects support setting pre-existing (added
before the object was made non-extensible
Brendan Eich:
No, not if the symbol is not in the whitelist. Zero information leak is
required.
That's good news too. Objection withdrawn. I guess I didn't correctly
understand David's point in the direct_proxies thread then :-/. I'll have to
reread it more carefully.
Thanks for the
Brendan Eich:
No, not if the symbol is not in the whitelist. Zero information leak is
required.
That's good news too. Objection withdrawn.
Maybe I gave up too easy :). Is the `unknownPrivateSymbol` trap called? What's
the rationale for this trap?
David Bruant wrote:
For the long term, I expected DOM objects could be proxified.
Boris convinced me otherwise for DOM Nodes at least.
Are you so convinced that the `unknownPrivateSymbol` trap is necessary?
It's been decided early that a Proxy.isProxy method should be avoided,
because
function isNodeProxy(node) {
try {
return node instanceof Node
document.body.appendChild(node)
!!document.body.removeChild(node);
} catch(x) {
return false;
}
}
Excuse me, I got the logic wrong:
Brendan Eich wrote:
Ease of teaching != successfully imparted knowledge at scale. Sorry, but
it's true. People don't use use strict; at top level enough, and
teaching them all will take time. Even then, because of the Law of Least
Effort, it'll be left out.
This is the major objection some
Brendan Eich wrote:
Herby Vojčík wrote:
Now I am confused.
For (p.q?).r to be same as p.q?.r, (p.q?) must return reified Nil, not
undefined. I was at the impression you say Nil at the background, but
whenever it becomes observable, it should be changed to undefined.
That means p.q?
Anton Kovalyov wrote:
anders elo wrote:
I'd like to propose the incorporation of multiple return values into
the ES standard.
function foo(){
return 1,2,3;
}
let (a,b,c) = foo();
let (a,b) = foo(); // ignore c
let (a,...b) = foo() // a = 1, b = [2,3]
/* also useful for
I never fully understood why the arguments object couldn't be an array, and I
know there is at least an attempted purge of the arguments object from the
language with the addition of rest parameters.. But, for the transitional
period, can the arguments object have an @@iterator property?
That's great news! Thank you!
Nathan
On Sat, Dec 22, 2012 at 4:57 PM, Nathan Wall
nathan.w...@live.commailto:nathan.w...@live.com wrote:
I never fully understood why the arguments object couldn't be an array,
and I know there is at least an attempted purge of the arguments object
from
Wat? This seems to be a good reason to allow `Object(NaN)` and use the
NumberWrapper brand as it cannot be tested via the normal way of
`myNaN !== myNaN`.
But `myNaN === myNaN` is true if `myNaN = Object(NaN)`. Testing against the
object is different. Nothing breaks.
var myNaN =
On another note, I do sort of wonder why `Number.isNaN` is coming into the
language now at the same time as the `is` operator and `Object.is`. It
seems teaching people (and getting them to remember long-term) the nuances
of `isNaN` and `Number.isNaN` will be more difficult than just
On Dec 11, 2012, at 10:19 AM, Andrea Giammarchi wrote:
Agreed, getOwnPropertyNames is way more appropriate if the topic is: use
all ES5 features for mixins too.
I totally agree as well.
Also, the Nicolas example is potentially disaster prone, not in that
specific form, but in the way a
The problem is that imports are not normal variable assignments. They
do not copy values, like normal destructuring, they are aliasing
bindings! If you were to allow arbitrary expressions and patterns,
then this would imply aliasing of arbitrary object properties. Not
only is this a
I see my previous email did not format well in the archive. I'm retrying this.
(Could someone please give me some formatting tips?)
Nathan
The problem is that imports are not normal variable assignments. They
do not copy values, like normal destructuring, they are aliasing
bindings! If you
Yeah, that makes sense. I agree. Thanks.
Nathan
On 9 December 2012 15:04, Nathan Wall nathan.w...@live.com wrote:
The problem is that imports are not normal variable assignments. They
do not copy values, like normal destructuring, they are aliasing
bindings! If you were to allow
Feel free to suggest alternatives, but forgive me if I'm not willing to
respond to every opinion on this one. :}
How about:
import ga as ga;
to import the whole module, and
import ga as { foo, bar };
to import just parts of the module. I feel like this makes a lot of sense, and
Date: Tue, 4 Dec 2012 11:03:57 -0800
From: bren...@mozilla.org
Subject: Re: (Map|Set|WeakMap)#set() returns `this` ?
Allen Wirfs-Brock wrote:
It's less clear which is the best choice for JS.
Cascading wants its own special form, e.g., Dave's
mustache-repurposed proposal at
I'm not a person of influence, but as a JS developer, I agree with Andrea on
this. I think Map#set() should return the value. I would expect the same
behavior as obj[key] = value. I find Andrea's use case (m.get(k) || m.set(k,
v)) more compelling than the method chaining possibilities.
Nathan
Object.defineProperty(obj,key, Object.create(defaultDataProperty, {value:
123});
Er, shouldn't that be:
Object.defineProperty(obj,key,Object.create(null, {value: {value: 123}}));
Seems pretty excessive. It's probably too late to make defineProperty only look
at own properties, but how about
Given the commonness of mixing one object into another, I was wondering how
this would work with private symbols -- considering methods will expect to find
those symbols on the objects on which they are called. Has there been any
discussion about providing a way to copy private symbols under
Looking at the recent draft, I noticed that the WeakMap methods accept
primitive keys, converting them to objects, and acting like an object was
passed in. This differs from the current behavior of Chrome and Firefox, which
both throw if key is not an object. It seems, as the current draft
85 matches
Mail list logo
