Re: Error stack
On Fri, Jun 8, 2012 at 6:48 PM, Erik Arvidsson erik.arvids...@gmail.com wrote: On Fri, Jun 8, 2012 at 4:10 PM, Charles Kendrick char...@isomorphic.com wrote: Once again, exposing the actual arguments, receiver and function object references is a security issue and completely out of scope for this. This is not related to cross domain access but related to object capabilities. Erik how do you reconcile this with the fact that this information can already be obtained in most production browsers via stack walking? Stack walking is not available in strict functions. Interesting, but it doesn't speak against programmatic access to the call stack. If use strict or any other security feature means that function.arguments are not accessible to a given script, then the same constraint could be trivially enforced with programmatic access to the call stack. The same could be applied to access to the receiver or values of local variables. In fact, V8's CallSite API makes the receiver inaccessible for a strict mode function (I just checked). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Error stack
Charles Kendrick wrote: On Fri, Jun 8, 2012 at 6:48 PM, Erik Arvidssonerik.arvids...@gmail.com wrote: On Fri, Jun 8, 2012 at 4:10 PM, Charles Kendrickchar...@isomorphic.com wrote: Once again, exposing the actual arguments, receiver and function object references is a security issue and completely out of scope for this. This is not related to cross domain access but related to object capabilities. Erik how do you reconcile this with the fact that this information can already be obtained in most production browsers via stack walking? Stack walking is not available in strict functions. Interesting, but it doesn't speak against programmatic access to the call stack. But you wrote how do you reconcile and Erik answered. We do not want a non-debugger API that works only some of the time. Debuggers, in contrast, must be able to pierce the veil of use strict. Erik's proposal is for the string-valued .stack property. A debugger API is further off from standardization. Mozilla has a new one: Video: http://www.youtube.com/watch?v=WKIkOcuVG7w https://wiki.mozilla.org/JSInspector https://wiki.mozilla.org/Remote_Debugging_Protocol https://wiki.mozilla.org/DevTools/Features/Debugger/Notes This is in Firefox Nightlies now. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Function length
Don't you want to use arguments.length instead of function.length?
On Jun 9, 2012 6:53 PM, Irakli Gozalishvili rfo...@gmail.com wrote:
I just noticed strange behavior in spider monkey implementation of rest
arguments:
(function(a, b, ...rest) {}).length // = 2
I think ignoring `rest` in length is pretty counter intuitive. For example
I have small utility function that
I use to dispatch depending on argument length.
var sum = dispatcher([
function() { return 0 },
function(x) { return x },
function(x, y) { return x + y },
function(x, y, z) { return Array.prototype.slice.call(arguments,
1).reduce(sum, x) }
])
This behavior of rest would obviously break assumptions made by this
library. That being said I don't think `3` would be any better. Maybe such
functions length should be:
- Infinity ?
- 2.5 ?
That way libraries would be able to handle them in a nice way:
var sum = dispatcher([
() = 0,
(x) = x,
(x, y) = x + y,
(x, ...rest) = rest.reduce(sum, x)
])
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
___
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: Function length
On Saturday, June 9, 2012 at 11:53 PM, Erik Arvidsson wrote:
Don't you want to use arguments.length instead of function.length?
On Jun 9, 2012 6:53 PM, Irakli Gozalishvili rfo...@gmail.com
(mailto:rfo...@gmail.com) wrote:
I just noticed strange behavior in spider monkey implementation of rest
arguments:
(function(a, b, ...rest) {}).length // = 2
I agree that this is strange, I would expect 3, as there are three formally
named parameters.
Rick
I think ignoring `rest` in length is pretty counter intuitive. For example
I have small utility function that
I use to dispatch depending on argument length.
var sum = dispatcher([
function() { return 0 },
function(x) { return x },
function(x, y) { return x + y },
function(x, y, z) { return Array.prototype.slice.call(arguments,
1).reduce(sum, x) }
])
This behavior of rest would obviously break assumptions made by this
library. That being said I don't think `3` would be any better. Maybe such
functions length should be:
- Infinity ?
- 2.5 ?
That way libraries would be able to handle them in a nice way:
var sum = dispatcher([
() = 0,
(x) = x,
(x, y) = x + y,
(x, ...rest) = rest.reduce(sum, x)
])
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
___
es-discuss mailing list
es-discuss@mozilla.org (mailto: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
