Java Enhancement Proposal 169: Value Objects

[Axel Rauschmayer]

http://openjdk.java.net/jeps/169

Looks familiar. ;-)

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: __proto__ and accessor descriptors

[David Bruant]

Le 09/11/2012 00:05, Jeff Walden a écrit :

On 10/26/2012 02:30 PM, David Bruant wrote:> Le 26/10/2012 22:56, Asen Bozhilov 
a écrit :

var obj = Object.defineProperty({}, '__proto__', {
 get : function () {return '__proto__ getter'},
 set : function (){return '__proto__ setter'}
});


console.log(obj.__proto__); //[object Object]
console.log(obj.__proto__ = {}); //[object Object]


On Firefox Aurora, I find:
"__proto__ getter"
"[object Object]"

According to this strawman, the output should indeed be
"__proto__getter" then "__proto__setter".

Given that the result of evaluating |obj.__proto__ = {}| is the right-hand side (the 
return value of calling the setter is ignored), to the extent there's some 
determined-correct behavior here, it definitely wouldn't be to log "__proto__ 
setter".

Jeff m'a tuer [1]

David

[1] Reference to "Omar m'a tuer", a case in France where the victim 
would have written the name of her murderer (Omar) with her own blood 
right before dying... but made an absurd typo (it should be "tuée" 
instead of "tuer"). A film has been made out of the case if anyone's 
interested http://en.wikipedia.org/wiki/Omar_Killed_Me

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Jeff Walden]

On 11/03/2012 11:06 PM, Mark S. Miller wrote:
> On Sat, Nov 3, 2012 at 10:13 PM, Axel Rauschmayer  > wrote:
>> (I am still sad we did not fix indexOf, lastIndexOf, and switch when we 
>> arguably had the chance.)
> 
> Can you elaborate? We don’t have the chance, any more? Would anything 
> break (or did, in tests)?
> 
> I am not aware of anyone gathering any evidence one way or the other about 
> what breakage this might cause. So it is not necessarily too late. If someone 
> does gather actual evidence that the breakage would be small enough, I could 
> see us reconsider this. But I doubt we would revisit in the absence of such 
> evidence. 

Just to note, there was a (at least this one) long thread on the topic (well, 
not including switch -- I don't remember a thread that considered changing 
switch) back in the day, if someone's invested enough in this to read it.

https://mail.mozilla.org/pipermail/es5-discuss/2009-August/003006.html

Jeff
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: __proto__ and accessor descriptors

[Brendan Eich]

Jeff Walden wrote:

On 10/26/2012 02:30 PM, David Bruant wrote:>  Le 26/10/2012 22:56, Asen 
Bozhilov a écrit :

var obj = Object.defineProperty({}, '__proto__', {
 get : function () {return '__proto__ getter'},
 set : function (){return '__proto__ setter'}
});


console.log(obj.__proto__); //[object Object]
console.log(obj.__proto__ = {}); //[object Object]


On Firefox Aurora, I find:
"__proto__ getter"
"[object Object]"

According to this strawman, the output should indeed be
"__proto__getter" then "__proto__setter".


Given that the result of evaluating |obj.__proto__ = {}| is the right-hand side (the 
return value of calling the setter is ignored), to the extent there's some 
determined-correct behavior here, it definitely wouldn't be to log "__proto__ 
setter".


Score! Good point.

David, if the setter calls console.log you should see the desired results.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: __proto__ and accessor descriptors

[Jeff Walden]

On 10/26/2012 02:30 PM, David Bruant wrote:> Le 26/10/2012 22:56, Asen Bozhilov 
a écrit :
>> var obj = Object.defineProperty({}, '__proto__', {
>> get : function () {return '__proto__ getter'},
>> set : function (){return '__proto__ setter'}
>> });
>>
>>
>> console.log(obj.__proto__); //[object Object]
>> console.log(obj.__proto__ = {}); //[object Object]
>>
> On Firefox Aurora, I find:
> "__proto__ getter"
> "[object Object]"
> 
> According to this strawman, the output should indeed be
> "__proto__getter" then "__proto__setter".

Given that the result of evaluating |obj.__proto__ = {}| is the right-hand side 
(the return value of calling the setter is ignored), to the extent there's some 
determined-correct behavior here, it definitely wouldn't be to log "__proto__ 
setter".

Jeff
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promises

[Mariusz Nowak]

Domenic Denicola-2 wrote:
> 
> If I understand correctly, promise.done(onFulfilled, onRejected) does what
> you want in Q and in WinJS. See
> 
> http://msdn.microsoft.com/en-us/library/windows/apps/hh700337.aspx
> 
> for a nice explanation from the WinJS folks.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 

When I scanned you're API not so long ago, it was as I described above. It
looks you've changed the behavior with one of the recent v0.8 rollouts and
that's definitely a good decision :)


-
Mariusz Nowak

https://github.com/medikoo
-- 
View this message in context: 
http://old.nabble.com/Promises-tp34648686p34655959.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at 
Nabble.com.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promises

[Domenic Denicola]

On Nov 8, 2012, at 6:45, "Mariusz Nowak"  
wrote:

> Q implementors spotted that issue, and provided `done` (initially named as
> `end`) function. Which helps to work with that issue:
> 
> promise.then(function () {
> // process the value
> }).done(); // Sugar for above
> 
> Still in Q (as far I as know) we're not able to get to resolved value
> without extending the promise chain and that's not great.

If I understand correctly, promise.done(onFulfilled, onRejected) does what you 
want in Q and in WinJS. See

http://msdn.microsoft.com/en-us/library/windows/apps/hh700337.aspx

for a nice explanation from the WinJS folks.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promises

[Mariusz Nowak]

Kevin Smith-21 wrote:
> 
> The only hard part that isn't really addressed by currently library
> implementations is error handling.  I feel pretty strongly that rejections
> (and by extension, errors thrown from `then` callbacks), should ALWAYS be
> observable.  In other words, if a rejection is not observable via error
> listeners at the time when error listeners should be called, then an
> unhandled error should be thrown by the runtime.
> 
> In my usage of promises I have never wanted anything other than this
> behavior.
> 
> 

I think source of a problem is that we center usage of promises just around
'then' function, when 'then' is about two things:
1. Provides us with resolved value
2. Extends promise chain with another promise.

What's important, in many use cases we're not after point 2, we don't need
extended promise, and it's promise extension fact that, makes our errors
silent when we don't expect them to be.

It's difficult to naturally expose errors when the only way to add observers
is `then`. Technically to do it we need to always write error handler as
below:

promise.then(function () {
  // process the value;
}).then(null, function (err) {
  // Need to get out of promise chain with setImmediate (or nextTick if in
Node.js)
  setImmediate(function (function () {
throw err; // Finally error will be thrown naturally;
  });
});

This one of the reasons for which some developers preferred to stay away
from promises, and I totally I agree with them.

Q implementors spotted that issue, and provided `done` (initially named as
`end`) function. Which helps to work with that issue:

promise.then(function () {
 // process the value
}).done(); // Sugar for above

Still in Q (as far I as know) we're not able to get to resolved value
without extending the promise chain and that's not great.

Final conclusion is that there needs to be a way to observe resolved value
on promise without extending the chain as `then` does.

And yes there is library that does that. In deferred implementation
(https://github.com/medikoo/deferred ) I've solved it by providing two other
functions that have same signature as 'then' but *don't extend* promise
chain:

promise.end(onFulfilled, onRejected); // returns undefined
If onRejected is not provided then failed promise will throw, additionally
any errors that may occur in provided callbacks are thrown natural way
(they're not caught by promise implementation)

promise.aside(onFulfilled, onRejected); // returns self promise
This actually works similar to functions found in jQuery's Deferred. It's
useful when we want to return same promise, but on a side, work with
resolved value. If onRejected is not provided nothing happens (as we return
promise for further processing), but any errors that occur in callbacks are
thrown natural way  (they're not caught by promise implementation)

With such design your function of choice in first place should always be
'end', in that case there is no problem with silent errors. `then` should be
used *only* if you have a reason to extend the chain, and pass result
elsewhere.


-
Mariusz Nowak

https://github.com/medikoo
-- 
View this message in context: 
http://old.nabble.com/Promises-tp34648686p34655893.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at 
Nabble.com.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Sandboxing and parsing jQuery in 100ms

[gaz Heyes]

For entertainment purposes I used MentalJS to parse itself. I found that I
had trailing commas in a couple of my object literals. Then I decided to
execute itself inside the sandbox:
eval("js=MentalJS();alert(js.parse('1+1'))");

I added an "inception" button to show how it does this. Parse time moves
slower inside dreams..I mean sandboxes.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss