not sure I understand those examples, but the moment a developer starts
yelding everything, is the moment all non-blovking asynchronous advantages
are gone 'cause you are waiting instead of keep doing the rest, isn't it?
On Sat, Apr 20, 2013 at 9:56 PM, Domenic Denicola
Anonymous export is simply about allowing library authors to indicate
a module's main entry point. Semantically, we're talking about the
difference between a string and a symbol; syntactically, we're talking
about one production. It's all cleanly layered on top of the rest of the
system. Let's
Hi Axel,
Le 21/04/2013 01:37, Axel Rauschmayer a écrit :
__proto__ can be globally switched off by deleting
Object.prototype.__proto__. I'm assuming that that is useful for
security-related applications (Caja et al.). But I'm wondering:
doesn't that go too far? I'm seeing three ways of using
On Sun, Apr 21, 2013 at 12:21 AM, Mark S. Miller erig...@google.com wrote:
I hesitate to put Module Loaders on the above list rather than leaving them
in ES6; but it would allow their semantics to rest on event loops and their
API to rest on promises. If we can get ES7 out quickly, this need
On Sun, Apr 21, 2013 at 12:56 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Finally, I know a lot of people, myself included, are excited about `await`
sugar. That is, the plan would be to use generators + promises in ES6 with
the awkwardness that entails; once we know what the
* Andrea Giammarchi wrote:
not sure I understand those examples, but the moment a developer starts
yelding everything, is the moment all non-blovking asynchronous advantages
are gone 'cause you are waiting instead of keep doing the rest, isn't it?
A simple example would be an application running
* Sam Tobin-Hochstadt wrote:
I don't see what the point of `await` is in your gist. It looks like
all of the work is being done by `function^`, which looks to be sugar
for creating a function and passing it to a scheduler like `Q.async`
or `taskjs.spawn`. We could add that sugar if we wanted,
On Sun, Apr 21, 2013 at 9:20 AM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Sam Tobin-Hochstadt wrote:
I don't see what the point of `await` is in your gist. It looks like
all of the work is being done by `function^`, which looks to be sugar
for creating a function and passing it to a scheduler
* Sam Tobin-Hochstadt wrote:
On Sun, Apr 21, 2013 at 9:20 AM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Sam Tobin-Hochstadt wrote:
I don't see what the point of `await` is in your gist. It looks like
all of the work is being done by `function^`, which looks to be sugar
for creating a function
On Apr 20, 2013, at 4:37 PM, Axel Rauschmayer wrote:
__proto__ can be globally switched off by deleting
Object.prototype.__proto__. I’m assuming that that is useful for
security-related applications (Caja et al.). But I’m wondering: doesn’t that
go too far? I’m seeing three ways of using
On Apr 21, 2013, at 5:22 AM, David Bruant wrote:
Hi Axel,
Le 21/04/2013 01:37, Axel Rauschmayer a écrit :
__proto__ can be globally switched off by deleting
Object.prototype.__proto__. I’m assuming that that is useful for
security-related applications (Caja et al.). But I’m wondering:
No.
/be
Claus Reinke wrote:
Anonymous export is simply about allowing library authors to indicate
a module's main entry point. Semantically, we're talking about the
difference between a string and a symbol; syntactically, we're
talking about one production. It's all cleanly layered on top of
On Apr 20, 2013, at 9:21 PM, Mark S. Miller erig...@google.com wrote:
* Communicating Event Loop concurrency model,
- with the two-priority event loop already required by both browser and
server.
* Object.observe
* Distribution compatible promises (at least Promises/A+)
*
Sorry, let me say a bit more.
You identified the entry-point idea. Good so far.
But then you went too far and made that entry-point, which with
anonymous export is often (but not always) a function, with the body of
the module, its top-level code.
A module is not a function. It is not
Brendan Eich wrote:
But then you went too far and made that entry-point, which with
anonymous export is often (but not always) a function, with
s/with/be/
the body of the module, its top-level code.
/jetlagged-be
___
es-discuss mailing list
Allen Wirfs-Brock wrote:
On Apr 21, 2013, at 5:22 AM, David Bruant wrote:
Hi Axel,
Le 21/04/2013 01:37, Axel Rauschmayer a écrit :
__proto__ can be globally switched off by deleting
Object.prototype.__proto__. I’m assuming that that is useful for
security-related applications (Caja et al.).
Domenic Denicola wrote:
This looks lovely.
The only thing I'd want to add: we need integers! And generally better numeric
types. From speaking to developers on the ground, this is the biggest missing
language feature they see (that isn't already addressed in ES6). I know Brendan
has made
Trimming cc: list to just es-discuss.
Mark S. Miller wrote:
* Completing the class design
- at least high integrity and private state
If I'm not mistaken, we need class-private syntax for classes to have
ultimate double-blind consensus in *ES6*. See last meeting notes.
At JQueryUK,
On Apr 21, 2013, at 8:55 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Deleting Object.prototype.__proto__ will not be be specified as disabling
{__proto__: foo}.
Was that what we'd agreed to? I hadn't remembered that. I don't like it because
it's special-case syntax, but I can also
you can hot-swap the chain, something Object.create() cannot do so it is
much more powerful, unless things changed that much lately ...
On Sun, Apr 21, 2013 at 11:03 AM, David Herman dher...@mozilla.com wrote:
On Apr 21, 2013, at 8:55 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
David Herman wrote:
On Apr 21, 2013, at 8:55 AM, Allen Wirfs-Brockal...@wirfs-brock.com wrote:
Deleting Object.prototype.__proto__ will not be be specified as disabling
{__proto__: foo}.
Was that what we'd agreed to?
I think what Allen means is, whether or not there's a magic
On Apr 21, 2013, at 11:03 AM, David Herman wrote:
On Apr 21, 2013, at 8:55 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Deleting Object.prototype.__proto__ will not be be specified as disabling
{__proto__: foo}.
Was that what we'd agreed to? I hadn't remembered that. I don't like
Allen Wirfs-Brock wrote:
On Apr 21, 2013, at 10:03 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
This isn't what we seemed to agree on at past TC39 meetings.
It's also not what the engines trying to converge on ES6 semantics have
implemented.
It's not clear to me, yet what convergence we
On Apr 21, 2013, at 11:12 AM, Brendan Eich wrote:
David Herman wrote:
On Apr 21, 2013, at 8:55 AM, Allen Wirfs-Brockal...@wirfs-brock.com wrote:
Deleting Object.prototype.__proto__ will not be be specified as disabling
{__proto__: foo}.
Was that what we'd agreed to?
I think what
Allen Wirfs-Brock wrote:
On Apr 21, 2013, at 11:12 AM, Brendan Eich wrote:
David Herman wrote:
On Apr 21, 2013, at 8:55 AM, Allen Wirfs-Brockal...@wirfs-brock.com wrote:
Deleting Object.prototype.__proto__ will not be be specified as disabling
{__proto__: foo}.
Was that what we'd agreed
Brendan Eich wrote:
Allen Wirfs-Brock wrote:
On Apr 21, 2013, at 11:12 AM, Brendan Eich wrote:
David Herman wrote:
On Apr 21, 2013, at 8:55 AM, Allen
Wirfs-Brockal...@wirfs-brock.com wrote:
Deleting Object.prototype.__proto__ will not be be specified as
disabling {__proto__: foo}.
Was
V8 already poisons when getOwnPropertyDescriptor has a setter and this
setters is the __proto__ one:
https://code.google.com/p/v8/source/browse/trunk/src/v8natives.js#390
This means V8 always throws and does not preserve the same realm, if I
understand what that means:
On Apr 21, 2013, at 11:53 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
...
This is specified by ES5, already.
Doesn't matter because what ES5 specifies is already incompatible with web
reality when the property name is __proto__.
No. Browsers implementing ES5 and de-facto
Allen that's correct/expected ... as __proto__ is own in the
Object.prototype only or am I missing something?
On Sun, Apr 21, 2013 at 12:21 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Apr 21, 2013, at 11:53 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
...
This is specified
On Apr 21, 2013, at 12:05 PM, Brendan Eich wrote:
What I mean is that:
let obj = {__proto__: null}
will always create an object whose [[Prototype]]
Didn't you mean an object whose property named '__proto__' here?
is null. Regardless of whether or not anybody has done:
delete
Allen Wirfs-Brock wrote:
On Apr 21, 2013, at 12:05 PM, Brendan Eich wrote:
What I mean is that:
let obj = {__proto__: null}
will always create an object whose [[Prototype]]
Didn't you mean an object whose property named '__proto__' here?
is null. Regardless of whether or not anybody
for how much I love being ignored, I agree on Brendan, once deleted, which
is an explicit action that means get this stuff out of my environment
nothing else should be affected.
If people would like to create enumerable/configurable/writable properties
at runtime together with specific
However, let's get back to (a) coffee :-); (b) ES6 and the ability to delete
Object.prototype.__proto__.
You don't want that to affect object literals evaluated in the same realm
after such a deletion. Why not?
[Sorry for cutting in, but this is the core point of my confusion.]
I’d
then you'll have ambiguous operations
obj[key] = value;
will not always do the same since
obj[key]
will not always do the same neither.
If a program decides/needs/wants no magic then magic should disappear and
if not in the chain it should not be inherited.
I'd rather leave, if really
On Apr 21, 2013, at 12:31 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
On Apr 21, 2013, at 12:05 PM, Brendan Eich wrote:
What I mean is that:
let obj = {__proto__: null}
will always create an object whose [[Prototype]]
Didn't you mean an object whose property named '__proto__'
Apparently Axel can ... he wants the inherited from nowhere getter
instead of passing through Object.getPrototypeOf(object) ... thing is Axel,
if you can get rid of __proto__ in the Object.prototype, and that property
simply disappears, you have all possibilities to redefine it as convenient
as
SpiderMonkey at least goes out of its way to do [[Set]] (let's call it)
not [[DefineOwnProperty]] for 'o = {__proto__: 42}', so why wouldn't
[[Set]] create a fresh property, seeing nothing on Object.prototype
named '__proto__' with a setter to run?
SpiderMonkey/JSC currently just use [[Set]]
Apparently Axel can ... he wants the inherited from nowhere getter instead
of passing through Object.getPrototypeOf(object) ... thing is Axel, if you
can get rid of __proto__ in the Object.prototype, and that property simply
disappears, you have all possibilities to redefine it as
love it ... reminds me those days when [] or {} were invoking Array and
Object in some env ...
Anyway, I believe Allen is trying to say that {__proto__:whatever} should
be spec'd as syntax, regardless what will be of the
Object.prototype.__proto__ property/descriptor so that you can get rid of
it
Allen Wirfs-Brock wrote:
On Apr 21, 2013, at 12:31 PM, Brendan Eich wrote:
You don't want that to affect object literals evaluated in the same realm
after such a deletion. Why not?
Why should it?
... because it did in ES5-conforming implementations that support
__proto__ as a de-facto
But then you went too far and made that entry-point, which with
anonymous export is often (but not always) a function, with the body
of the module, its top-level code.
I suggested that modules be callable, executing the module body and
returning what would be the anonymous export. I did not
2013/4/21 Allen Wirfs-Brock al...@wirfs-brock.com
Also note that JSON.parse('{__proto__: null}') does not create an object
whose [[Protoype]] is null because JSON.parse uses [[DefineOwnProperty]] to
create all its properties so this will just result in an own property whose
value is null.
Le 21/04/2013 19:09, Brendan Eich a écrit :
Domenic Denicola wrote:
Doing a quick poll of some IRC rooms, there's some call for
shared-memory multithreading. I know this was a concern of the asm.js
project, or more generally for the JS-as-a-compilation-target
mission. I don't think this is a
agreed for consistency too, once deleted, the magic should disappear 100%
reality will be that most devs won't delete it so I don't see concrete side
effects out there.
However, this is how I would spec it (or better, how I would drop the axe
accepting a compromise for this property)
apologies, I've realized SES might want more something like this:
(function(getOwnPropertyDescriptor){
Object.defineProperty(
Object,
'getOwnPropertyDescriptor',
{
enumerable: false,
configurable: false,
writable: false,
value: function(object, property) {
On Sun, Apr 21, 2013 at 1:37 PM, Brendan Eich bren...@mozilla.com wrote:
Allen Wirfs-Brock wrote:
On Apr 21, 2013, at 12:31 PM, Brendan Eich wrote:
You don't want that to affect object literals evaluated in the same
realm after such a deletion. Why not?
Why should it?
... because it
Off Topic: it's really funny that it took 10 years to teach people how
inheritance works in JS and today there's some legacy that instead of
constructors uses their objects or just objects as prototype so that
{__proto__:whatever} is considered a used pattern.
If the most common case is
Warning: The following is a sickening idea. I would really hate to see us
do it. But I feel obliged to post it as it may in fact be the right thing
to do.
Given: Web reality drives us towards recognizing {, __proto__: ,
} as special syntax for initializing [[Prototype]].
Given:
that won't work?
__proto__ in {__proto__:{}}; // true
__proto__ in {__proto__:{}}; // still true, since __proto__ in
Object.prototype, unless deleted
am I wrong?
On Sun, Apr 21, 2013 at 3:27 PM, Mark S. Miller erig...@google.com wrote:
Warning: The following is a sickening idea. I would
For some subset of use cases I imagine shared-memory multithreading being
limited to immutable objects could do the trick. Of course, I don't know if
real immutability is actually possible in ES as currently specified - if I
called Object.freeze or Object.seal on a JS object would it actually be
uh wait ... you meant ... uh ... wait, sorry, OK :D
so {__proto__:Array.prototype} is an instanceof Array
{__proto__:Array.prototype} is an object with a __proto__ property that
points to Array.prototype
which means that __proto__ is magically overwritten ... yak?!
On Sun, Apr 21, 2013 at
that said, I like the dual behavior if not because there's no way even by
accident somebody can change a prototype chain in a for/in loop
var copied = {__proto__:null,__proto__:Array.prototype};
var copy = {};
for (var key in copied) {
if (copied.hasOwnProperty(key)) {
copy[key] =
isn't typeof (console.log) function and not object? by object I meant
an Object object, not 'any arbitrary JS value'. I suppose the distinction
is really blurry, and you would still have to deal with problems like the
object's prototype chain containing callables...
On Sun, Apr 21, 2013 at 3:42
Then consider `Object.freeze(console)`.
Fundamentally, frozen objects are not appropriate for prohibiting shared state.
Sam
On Sun, Apr 21, 2013 at 6:44 PM, Kevin Gadd kevin.g...@gmail.com wrote:
isn't typeof (console.log) function and not object? by object I meant an
Object object, not 'any
Mark S. Miller wrote:
For all parties, some examples of legacy uses of {__proto__: },
whether hypothetical or observed, would help a lot. I doubt the stance
special literal syntax for initializing [[Prototype]] without using
either [[Put]]/[[Set]] nor [[DefineOwnProperty]] would be
On Apr 21, 2013, at 1:37 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
On Apr 21, 2013, at 12:31 PM, Brendan Eich wrote:
You don't want that to affect object literals evaluated in the same realm
after such a deletion. Why not?
Why should it?
... because it did in ES5-conforming
We're not concerned if there is *any* such implementation. We care about
the intersection of enough implementations that it becomes an issue for
cross-browser code. And code that only works on one browser has been code
that we've always[1] been willing to break going forward.
[1] At least during
On Apr 21, 2013, at 3:11 PM, Mark S. Miller wrote:
On Sun, Apr 21, 2013 at 1:37 PM, Brendan Eich bren...@mozilla.com wrote:
Allen Wirfs-Brock wrote:
On Apr 21, 2013, at 12:31 PM, Brendan Eich wrote:
You don't want that to affect object literals evaluated in the same realm
after such a
On Apr 21, 2013, at 3:27 PM, Mark S. Miller wrote:
Warning: The following is a sickening idea. I would really hate to see us do
it. But I feel obliged to post it as it may in fact be the right thing to do.
Given: Web reality drives us towards recognizing {, __proto__: ,
}
On Sun, Apr 21, 2013 at 6:11 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Apr 21, 2013, at 1:37 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
On Apr 21, 2013, at 12:31 PM, Brendan Eich wrote:
You don't want that to affect object literals evaluated in the same
realm after
On Sun, Apr 21, 2013 at 6:21 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Apr 21, 2013, at 3:27 PM, Mark S. Miller wrote:
Warning: The following is a sickening idea. I would really hate to see
us do it. But I feel obliged to post it as it may in fact be the right
thing to do.
Agreed that Object.freeze does not give you what you need.
RiverTrail already needs a kind of collection that is transitively
immutable by construction. They need this for safe data parallelism. But
the reason they are safe for parallel access within a vat/worker is the
same reason they would be
On Sun, Apr 21, 2013 at 6:11 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
We are free to specify a semantics that will make sense, now and for the
long term.
then, for the long term, if all I understood about this thing is that
stinks for everybody, you should really consider to give
Hi Andrea, Allen's immediately previous sentence was
The point is that I don't think there is any long standing behavior in
this regard relating to object literals and deleting
Object.prototype.__proto__ that the web is dependent upon.
This sets the context for understanding Allen's next
So as my last post said, if there's no observable difference in the
field in switching from [[Put]] to [[SetInheritance]], then you and Mark
are right, and we can do that in ES6 without fear of breaking any code.
This change *is* observable in ES6, though. That's why I summoned Mark:
to make
Andrea may be asking for less than the standard someday removing
__proto__, if I read him right. He's asking not to keep it
indestructible, i.e., to make
delete Object.prototype.__proto__
remove all the magic, including for 'o = {__proto__: p}'.
But that seems to require using [[Put]]
Again, you're inventing something new. Always risky, ignoring the
throw-up-in-mouth effect :-|.
Now the burden is on someone (who?) to find code on the web that uses
the quoted form expecting the same results as the unquoted form, which
is what all implementations I know of indeed provide.
On Sun, Apr 21, 2013 at 8:41 PM, Brendan Eich bren...@mozilla.com wrote:
So as my last post said, if there's no observable difference in the field
in switching from [[Put]] to [[SetInheritance]], then you and Mark are
right, and we can do that in ES6 without fear of breaking any code.
This
yep, I was asking to make it neutral 100% but that specific case, as
written many replies before not only by me, seems to be reasonable, as long
as delete Object.prototype.__proto__ is possible and, if this is possible,
hoping that Object.getOwnPropertyDescriptor(Object.prototype,
'__proto__').set
Ok, so (after pushing back based on recorded consensus, which I think is
fair), I'm ok with
* Object.prototype.__proto__ is configurable.
* o = {__proto__: p} semantics changes from ES5's [[Put]] to ES6's
[[SetInheritance]].
I'm not sure everyone agrees, but let's assume these two.
Why,
On Sun, Apr 21, 2013 at 8:45 PM, Brendan Eich bren...@mozilla.com wrote:
Andrea may be asking for less than the standard someday removing
__proto__, if I read him right. He's asking not to keep it
indestructible, i.e., to make
delete Object.prototype.__proto__
remove all the magic,
On Sun, Apr 21, 2013 at 9:42 PM, Brendan Eich bren...@mozilla.com wrote:
Ok, so (after pushing back based on recorded consensus, which I think is
fair), I'm ok with
* Object.prototype.__proto__ is configurable.
* o = {__proto__: p} semantics changes from ES5's [[Put]] to ES6's
if Object.getPrototypeOf() works there, how is that secret protected?
In any case, do you agree since you can configure
Object.prototype.__proto__ you could also poison it by your own instead of
proposing an unusable poisoned setter as it is now in V8?
I am talking about this possibility
On Sun, Apr 21, 2013 at 9:56 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
if Object.getPrototypeOf() works there, how is that secret protected?
Assuming the script does not make the object that the literal evaluates to
available to the hostile environment it is running it. This
right now this is the V8 situation:
https://code.google.com/p/v8/issues/detail?id=2645
which is different from SpiderMonkey one where you can:
var protoSetter = Object.getOwnPropertyDescriptor(
Object.prototype, '__proto__'
);
delete Object.prototype.__proto__; // optionally
var a = {}, b =
oh dear ...
var protoSetter = Object.getOwnPropertyDescriptor(
Object.prototype, '__proto__'
).set; // forgot the setter in previous example
On Sun, Apr 21, 2013 at 10:07 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
right now this is the V8 situation:
76 matches
Mail list logo
