Why not NodeList#forEach :\?
[].forEach.call(NodeList,function(elm) {}) why that? Why not treat it like
an [] ?
--
*'I am what I am because of who we all are'*
h3manth.com http://www.h3manth.com
*-- Hemanth HM *
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Why not NodeList#forEach :\?
Hi,
Le 11/06/2012 12:30, Hemanth H.M a écrit :
[].forEach.call(NodeList,function(elm) {}) why that? Why not treat it
like an [] ?
I've written a section on MDN specifically a while ago to answer that
very question:
https://developer.mozilla.org/En/DOM/NodeList#Why_can%27t_I_use_forEach_or_map_on_a_NodeList.3F
Regardless, that's not in ECMAScript's scope. ECMAScript is about the
language (syntax, semantics, etc.), while NodeList are part of the DOM
which can be considered as an ECMAScript library. However, of course,
browsers all ship this library by default. It is however not present
in server-side environments like Node.js.
A longer time ago, I wrote another page to describe what JavaScript
mean, because it has become an umbrella term to talk about a lot of
different technologies:
https://developer.mozilla.org/en/JavaScript_technologies_overview
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Why not NodeList#forEach :\?
Thank you very much for the clarification! Also noticed 'Extending the DOM
is dangerous.'
On Mon, Jun 11, 2012 at 4:16 PM, David Bruant bruan...@gmail.com wrote:
Hi,
Le 11/06/2012 12:30, Hemanth H.M a écrit :
[].forEach.call(NodeList,**function(elm) {}) why that? Why not treat it
like an [] ?
I've written a section on MDN specifically a while ago to answer that very
question: https://developer.mozilla.org/**En/DOM/NodeList#Why_can%27t_I_**
use_forEach_or_map_on_a_**NodeList.3Fhttps://developer.mozilla.org/En/DOM/NodeList#Why_can%27t_I_use_forEach_or_map_on_a_NodeList.3F
Regardless, that's not in ECMAScript's scope. ECMAScript is about the
language (syntax, semantics, etc.), while NodeList are part of the DOM
which can be considered as an ECMAScript library. However, of course,
browsers all ship this library by default. It is however not present in
server-side environments like Node.js.
A longer time ago, I wrote another page to describe what JavaScript
mean, because it has become an umbrella term to talk about a lot of
different technologies: https://developer.mozilla.org/**
en/JavaScript_technologies_**overviewhttps://developer.mozilla.org/en/JavaScript_technologies_overview
David
--
*'I am what I am because of who we all are'*
h3manth.com http://www.h3manth.com
*-- Hemanth HM *
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ecmascript 6 annotated available ? EOM
-- *'I am what I am because of who we all are'* h3manth.com http://www.h3manth.com *-- Hemanth HM * ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Function length
On 10 June 2012 03:52, 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) }
])
I don't think any library should ever rely on f.length. It is not a
reliable source of information (f might use 'arguments' even when the
length is officially 0), and I don't honestly see it being useful for
anything but tertiary debugging purposes.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Zed A. Shaw - The Web Will Die When OOP Dies
Hi, I'm wondering what's the point of posting just a video like this. Do you have specific needs? Are there issues you want to discuss? We all want sugar. I came to es-discuss as a developer (which I still am) and I wish there was more sugar and that's in part what is being discussed here on a daily basis. Over the last couple of years, we have seen a tremendous amount of conferences by TC39ers at dev conferences to gather feedback from developers who work with the language on a daily basis. TC39 is open to feedback from developers What more or different do you want? If you can't answers these questions, don't expect things to move forward. David Le 10/06/2012 14:27, Hemanth H.M a écrit : Sugar, I want more sugar! http://vimeo.com/43380467 -- /'I am what I am because of who we all are'/ h3manth.com http://www.h3manth.com /-- Hemanth HM/ ___ 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: Zed A. Shaw - The Web Will Die When OOP Dies
Well, I came looking for sugar, was reading few of the proposal which already covers my needs, will update as soon as I get anything either than those in the proposal. /me understands that just a video link is too very wage, but, felt it made few strong suggestions. How can one contribute ( as in code to ES or Javascript ) ? On Mon, Jun 11, 2012 at 6:19 PM, David Bruant bruan...@gmail.com wrote: We all want sugar. I came to es-discuss as a developer (which I still am) and I wish there was more sugar and that's in part what is being discussed here on a daily basis. Over the last couple of years, we have seen a tremendous amount of conferences by TC39ers at dev conferences to gather feedback from developers who work with the language on a daily basis. TC39 is open to feedback from developers -- *'I am what I am because of who we all are'* h3manth.com http://www.h3manth.com *-- Hemanth HM * ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why not NodeList#forEach :\?
Wow, that's interesting. When will that be implemented?
On Mon, Jun 11, 2012 at 5:59 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Monday, June 11, 2012 at 6:30 AM, Hemanth H.M wrote:
[].forEach.call(NodeList,function(elm) {}) why that? Why not treat it like
an [] ?
ES6 draft specifies a new Array constructor called Array.from that will
essentially convert array-likes into arrays:
Array.from( nodes ).forEach(...
Rick
--
*'I am what I am because of who we all are'*
h3manth.com http://www.h3manth.com
*-- Hemanth HM *
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
*'I am what I am because of who we all are'*
h3manth.com http://www.h3manth.com
*-- Hemanth HM *
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Why not NodeList#forEach :\?
Le 11/06/2012 14:56, Hemanth H.M a écrit :
Wow, that's interesting. When will that be implemented?
Depends on browsers. Good news is that you can polyfill it today! :-)
Actually, that could be a good fit for https://github.com/paulmillr/es6-shim
David
On Mon, Jun 11, 2012 at 5:59 PM, Rick Waldron waldron.r...@gmail.com
mailto:waldron.r...@gmail.com wrote:
On Monday, June 11, 2012 at 6:30 AM, Hemanth H.M wrote:
[].forEach.call(NodeList,function(elm) {}) why that? Why not
treat it like an [] ?
ES6 draft specifies a new Array constructor called Array.from that
will essentially convert array-likes into arrays:
Array.from( nodes ).forEach(...
Rick
--
/'I am what I am because of who we all are'/
h3manth.com http://www.h3manth.com
/-- Hemanth HM/
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
/'I am what I am because of who we all are'/
h3manth.com http://www.h3manth.com
/-- Hemanth HM/
___
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: Why not NodeList#forEach :\?
ES6 draft specifies a new Array constructor called Array.from that will essentially convert array-likes into arrays This will have uses for the arguments objects too, for people that aren't using ...rest in ES6. Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why not NodeList#forEach :\?
Uber kool! Thanks a ton David!
npm install es6-shim # wow :) Shall blog about this!
Well, Map() and Set() is already there is FF13, it's an experimental API
right? Experimental means it can be chucked off or it shall be modified
drastically ? ( More Java like APIs :\ )
Well {} behaved liked map and well for sets we can use [].sort.filter(
function(v,i,o){return v!==o[i-1];}
On Mon, Jun 11, 2012 at 6:30 PM, David Bruant bruan...@gmail.com wrote:
https://github.com/paulmillr/es6-shim
--
*'I am what I am because of who we all are'*
h3manth.com http://www.h3manth.com
*-- Hemanth HM *
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Why not NodeList#forEach :\?
Ha Hmm, yet to iterate sets. On Mon, Jun 11, 2012 at 6:48 PM, David Bruant bruan...@gmail.com wrote: http://productforums.google.com/forum/#!topic/docs/0hQWeOvCcHU -- *'I am what I am because of who we all are'* h3manth.com http://www.h3manth.com *-- Hemanth HM * ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why not NodeList#forEach :\?
Le 11/06/2012 15:23, Hemanth H.M a écrit : Ha Hmm, yet to |iterate| sets For...of loop may be of some help here. Good introductory article by Axel Rauschmayer from this morning (doesn't talk about Sets, but it should work I think): http://www.2ality.com/2012/06/for-of-ff13.html David On Mon, Jun 11, 2012 at 6:48 PM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: http://productforums.google.com/forum/#!topic/docs/0hQWeOvCcHU http://productforums.google.com/forum/#%21topic/docs/0hQWeOvCcHU -- /'I am what I am because of who we all are'/ h3manth.com http://www.h3manth.com /-- Hemanth HM/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why not NodeList#forEach :\?
On Mon, Jun 11, 2012 at 9:09 AM, Tom Ellis tellis...@gmail.com wrote: ES6 draft specifies a new Array constructor called Array.from that will essentially convert array-likes into arrays This will have uses for the arguments objects too, for people that aren't using ...rest in ES6. Indeed - Array.from can be used with any object that has a numeric index and length property whose value is a number - which covers a very wide swath of Ecmascript/non-Ecmascript objects. Rick Tom ___ 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: ecmascript 6 annotated available ? EOM
On Mon, Jun 11, 2012 at 6:59 AM, Hemanth H.M hemanth...@gmail.com wrote: The current spec draft is available here: http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts There are several formats, with and without change notations Rick -- *'I am what I am because of who we all are'* h3manth.com http://www.h3manth.com *-- Hemanth HM * ___ 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: Zed A. Shaw - The Web Will Die When OOP Dies
On Mon, Jun 11, 2012 at 8:54 AM, Hemanth H.M hemanth...@gmail.com wrote: snip How can one contribute ( as in code to ES or Javascript ) ? It's been my immediate, personal experience that participation itself is the best form of contribution. Be thoughtful, do research, think critically, etc. Listen and learn, speak up when it makes sense to do so. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ecmascript 6 annotated available ? EOM
Just came across that, thanks :) On Mon, Jun 11, 2012 at 7:17 PM, Rick Waldron waldron.r...@gmail.comwrote: On Mon, Jun 11, 2012 at 6:59 AM, Hemanth H.M hemanth...@gmail.com wrote: The current spec draft is available here: http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts There are several formats, with and without change notations Rick -- *'I am what I am because of who we all are'* h3manth.com http://www.h3manth.com *-- Hemanth HM * ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- *'I am what I am because of who we all are'* h3manth.com http://www.h3manth.com *-- Hemanth HM * ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why not NodeList#forEach :\?
Thank you Rick Waldron :) BTW tired 'es6-shim' on node.js and : Math.sign(-0) -1 Should it give an error? On Mon, Jun 11, 2012 at 7:14 PM, Rick Waldron waldron.r...@gmail.comwrote: On Mon, Jun 11, 2012 at 9:09 AM, Tom Ellis tellis...@gmail.com wrote: ES6 draft specifies a new Array constructor called Array.from that will essentially convert array-likes into arrays This will have uses for the arguments objects too, for people that aren't using ...rest in ES6. Indeed - Array.from can be used with any object that has a numeric index and length property whose value is a number - which covers a very wide swath of Ecmascript/non-Ecmascript objects. Rick Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- *'I am what I am because of who we all are'* h3manth.com http://www.h3manth.com *-- Hemanth HM * ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why not NodeList#forEach :\?
Awesome. I've had es6-shim for a while now but I haven't used it yet. I forgot what its use was until now. Tom On 11 Jun 2012, at 14:44, Rick Waldron wrote: On Mon, Jun 11, 2012 at 9:09 AM, Tom Ellis tellis...@gmail.com wrote: ES6 draft specifies a new Array constructor called Array.from that will essentially convert array-likes into arrays This will have uses for the arguments objects too, for people that aren't using ...rest in ES6. Indeed - Array.from can be used with any object that has a numeric index and length property whose value is a number - which covers a very wide swath of Ecmascript/non-Ecmascript objects. Rick Tom ___ 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: Why not NodeList#forEach :\?
On Jun 11, 2012, at 7:00 AM, Hemanth H.M wrote: Thank you Rick Waldron :) BTW tired 'es6-shim' on node.js and : Math.sign(-0) -1 Should it give an error? You could find the answer to that by checking the draft specification at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts See section 15.8.2.31 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Add basic arithmetic to Math
On Jun 10, 2012, at 11:48 AM, Angus Croll wrote: Rationale: Some functional JavaScript idioms are hamstrung by the lack of native basic arithmetic functions. Would be handy/elegant/instructive to be able to write arr.reduce(Math.add); Moreover having functional versions of arithmetic operators would improve the currying/partial/composition experience. Caveats: 1. Arrow functions work pretty well too: arr.reduce((a,b)=a+b); These seems better, non-invasive approach rather than than adding built-in functions corresponding to every built-in operator. Also, nothing preventing somebody from creating a library of such functions. 2. If add and multiply accepted multiple args, reduce would not be necessary for these cases: Math.add.apply(null, arr); Math.add(...arr) Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why not NodeList#forEach :\?
Not quite impossible, you just have to get a bit creative. While certainly
not as fast as a built in implementation, the method used here is still
O(1). https://github.com/Benvie/ES6-Harmony-Collections-Shim
The major use case for Maps and Sets (as far as i'm concerned) is the
ability to use objects as keys. Having built-in implementation of these
potentially enable O(1)-ish lookups (which is impossible to implement in
JavaScript).
As to Maps and {} being equivalent, that's true expect when it's not, like
when you want to use pseudo properties like __proto__ or __noSuchMethod__
as keys. Some folks tried to use objects as maps and got burned [1]. See
Caja's StringMap [2] for a workaround when you only need strings as keys.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Function length
I don't think any library should ever rely on f.length.
That's a wrong attitude, there always will be legitimate uses of any feature,
otherwise such features are just harmful IMO should be deprecated / removed.
It is not a
reliable source of information (f might use 'arguments' even when the
length is officially 0), and I don't honestly see it being useful for
anything but tertiary debugging purposes.
In some cases weather function captures `rest` arguments via `arguments` is
irrelevant. Like in a case I've pointed out earlier. Library provides arity
based dispatch based on f.length, so if you pass `function() { arguments…. }`
it will never be called with more than 0 arguments.
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
On Monday, 2012-06-11 at 05:33 , Andreas Rossberg wrote:
On 10 June 2012 03:52, 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 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) }
])
I don't think any library should ever rely on f.length. It is not a
reliable source of information (f might use 'arguments' even when the
length is officially 0), and I don't honestly see it being useful for
anything but tertiary debugging purposes.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Function length
On Jun 11, 2012, at 10:56 AM, Irakli Gozalishvili wrote: I don't think any library should ever rely on f.length. That's a wrong attitude, there always will be legitimate uses of any feature, otherwise such features are just harmful IMO should be deprecated / removed. Let me try again. We don't understand your use case. You didn't show us the definition of your dispatch function so we have to guess. Even so, It is hard to imagine a legitimate use with dynamically provided functions, particularly as the length values assigned to the existing built-ins don't follow strict rules. At the very least you need to help us understand why your use case is both reasonable and valid. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Function length
I would not mind removing Function 'length' but on the web you cannot
deprecate and any browser daring to remove will appear broken to users
not involved in the content or the engine, and users switch browsers.
Anyway, back to reality: foo.length is in ECMA-262 and we need to spec
how it works in the presence of a trailing rest parameter. Allen has
drafted something based on discussion here. It's a plausible design and
hard to criticize without both your use-case (in detail) and a better
alternative.
/be
Irakli Gozalishvili wrote:
I don't think any library should ever rely on f.length.
That's a wrong attitude, there always will be legitimate uses of any
feature, otherwise such features are just harmful IMO should be
deprecated / removed.
It is not a
reliable source of information (f might use 'arguments' even when the
length is officially 0), and I don't honestly see it being useful for
anything but tertiary debugging purposes.
In some cases weather function captures `rest` arguments via
`arguments` is irrelevant. Like in a case I've pointed out earlier.
Library provides arity based dispatch based on f.length, so if you
pass `function() { arguments…. }` it will never be called with more
than 0 arguments.
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
On Monday, 2012-06-11 at 05:33 , Andreas Rossberg wrote:
On 10 June 2012 03:52, 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 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) }
])
I don't think any library should ever rely on f.length. It is not a
reliable source of information (f might use 'arguments' even when the
length is officially 0), and I don't honestly see it being useful for
anything but tertiary debugging purposes.
/Andreas
___
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
Sorry for not being clear about this. Here is a simplified example of the implementation: https://gist.github.com/2911817 Also this is just a single particular example, but I expect there to be more. I think what I'm really asking for is a way to know if …rest is being used. Also IMO arrow functions should not have `arguments` at all. Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ On Monday, 2012-06-11 at 11:04 , Allen Wirfs-Brock wrote: On Jun 11, 2012, at 10:56 AM, Irakli Gozalishvili wrote: I don't think any library should ever rely on f.length. That's a wrong attitude, there always will be legitimate uses of any feature, otherwise such features are just harmful IMO should be deprecated / removed. Let me try again. We don't understand your use case. You didn't show us the definition of your dispatch function so we have to guess. Even so, It is hard to imagine a legitimate use with dynamically provided functions, particularly as the length values assigned to the existing built-ins don't follow strict rules. At the very least you need to help us understand why your use case is both reasonable and valid. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Error stack
On Sat, Jun 9, 2012 at 12:26 PM, Brendan Eich bren...@mozilla.org wrote: We do not want a non-debugger API that works only some of the time. What we want (IMO) is an API that allows runtime diagnostics to be collected. By necessity, function arguments would be unavailable for some stack frames. This is not a new situation or a flaw in the proposal, it's a situation which exists already for the function.arguments API. Debuggers, in contrast, must be able to pierce the veil of use strict. Clearly. A debugger API is further off from standardization. Mozilla has a new one: ... This is great but pretty much unrelated - clearly we shouldn't cripple a runtime diagnostic API because there's a debugger API - these are two different use cases. Let's get concrete here - because function.arguments is actually available but not exposed by error.stack, we have implemented a system that parses error.stack, using its information to find live function instances, grabs the arguments and receiver from those and injects them into a new, enhanced stack trace which we log. And of course we have to cover the recursive case and show the arguments as not available.. Because runtime diagnostic information like this is so critical, you'll see this approach being taken by a bunch of frameworks - don't you find this distasteful and a clear indication that the standard should be exposing this information directly? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Function length
I find Function 'length' as very useful property (I use it in some low-level
functional stuff). I also think that defining functions so it reflects only
required arguments is very sane decision. In that light I would also expect
...rest to not be counted in Function length.
+1 for keeping it, the way it is.
Brendan Eich-2 wrote:
I would not mind removing Function 'length' but on the web you cannot
deprecate and any browser daring to remove will appear broken to users
not involved in the content or the engine, and users switch browsers.
Anyway, back to reality: foo.length is in ECMA-262 and we need to spec
how it works in the presence of a trailing rest parameter. Allen has
drafted something based on discussion here. It's a plausible design and
hard to criticize without both your use-case (in detail) and a better
alternative.
/be
Irakli Gozalishvili wrote:
I don't think any library should ever rely on f.length.
That's a wrong attitude, there always will be legitimate uses of any
feature, otherwise such features are just harmful IMO should be
deprecated / removed.
It is not a
reliable source of information (f might use 'arguments' even when the
length is officially 0), and I don't honestly see it being useful for
anything but tertiary debugging purposes.
In some cases weather function captures `rest` arguments via
`arguments` is irrelevant. Like in a case I've pointed out earlier.
Library provides arity based dispatch based on f.length, so if you
pass `function() { arguments…. }` it will never be called with more
than 0 arguments.
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
On Monday, 2012-06-11 at 05:33 , Andreas Rossberg wrote:
On 10 June 2012 03:52, 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 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) }
])
I don't think any library should ever rely on f.length. It is not a
reliable source of information (f might use 'arguments' even when the
length is officially 0), and I don't honestly see it being useful for
anything but tertiary debugging purposes.
/Andreas
___
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
-
Mariusz Nowak
https://github.com/medikoo
--
View this message in context:
http://old.nabble.com/Function-length-tp33987815p33995683.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: Function length
Irakli Gozalishvili wrote: Sorry for not being clear about this. Here is a simplified example of the implementation: https://gist.github.com/2911817 Also this is just a single particular example, but I expect there to be more. I think what I'm really asking for is a way to know if …rest is being used. Your code doesn't work on a function that uses arguments the old fashioned way, though. Yes, you can make ...rest affect .length and make a dispatcher that counts on that, but it's a just-so story and a hard case. Hard cases make bad law. If it really matters, we can provide better reflection facilities, but I'm pretty sure it doesn't occur enough to justify doing so now. So use the toString hack if you must and let's see if this use-case becomes hot. Also IMO arrow functions should not have `arguments` at all. That's already in the proposal: http://wiki.ecmascript.org/doku.php?id=harmony:arrow_function_syntax The /Identifier/ primary expression |arguments| may not be used in an arrow function’s body (whether expression or block form). /be Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ On Monday, 2012-06-11 at 11:04 , Allen Wirfs-Brock wrote: On Jun 11, 2012, at 10:56 AM, Irakli Gozalishvili wrote: I don't think any library should ever rely on f.length. That's a wrong attitude, there always will be legitimate uses of any feature, otherwise such features are just harmful IMO should be deprecated / removed. Let me try again. We don't understand your use case. You didn't show us the definition of your dispatch function so we have to guess. Even so, It is hard to imagine a legitimate use with dynamically provided functions, particularly as the length values assigned to the existing built-ins don't follow strict rules. At the very least you need to help us understand why your use case is both reasonable and valid. Allen ___ 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: Error stack
Charles Kendrick wrote: On Sat, Jun 9, 2012 at 12:26 PM, Brendan Eichbren...@mozilla.org wrote: We do not want a non-debugger API that works only some of the time. What we want (IMO) is an API that allows runtime diagnostics to be collected. By necessity, function arguments would be unavailable for some stack frames. This is not a new situation or a flaw in the proposal, it's a situation which exists already for the function.arguments API. It seems to me we've lost the thread (maybe you haven't, but I have -- apologies for revisiting). I replied because of this flow: CK: Erik how do you reconcile this with the fact that this information can already be obtained in most production browsers via stack walking? EA: Stack walking is not available in strict functions CK: Interesting, but it doesn't speak against programmatic access to the call stack. At this point I'm not sure what you want -- object references to calling functions? You're right that we could disclose those where use strict does not poison function.arguments and arguments.callee already, but to what end? Erik's proposal was about standardizing a string-valued .stack property. If we can't have a common string-valued .stack property, we could still make a new one (.stackString or some such; yech) that doesn't include object references. Is there a strong motivation for sometimes exposing (where use strict allows) object references, or would your use-cases be met by some better string-valued spec? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Error stack
It seems to me we've lost the thread (maybe you haven't, but I have -- apologies for revisiting). In a nutshell, I'm looking for access to function arguments, the receiver, and ideally even local variable values via *some* runtime diagnostic API. These could be all be exposed in an error.stack String or in a more OO API (say, error.stackFrames as an array of objects with various properties). I think the best solution is to have *both*. In the field right now, error.stack is a String. Adding error.stackFrames this would mean: 1. we avoid breaking code in the field 2. we provide a convenient error.stack for people who don't want to deal with error.stackFrames 3. we avoid people who want to add richer information having to parse an error.stack String 4. we eliminate all the issues we're running into in trying to standardize error.stack; it wouldn't be so important for it to expose more information or have really smart formatting rules like I previously proposed [1]. It would no longer need to be machine parsable. It might even be OK for it's format to remain completely unspecified since it's just a convenience. The confusing bit: Erik objected to making arguments available in error.stack for security reasons, and Erik is correct that use strict implies arguments would not be available in that case. However, I see no issue with error.stack or an error.stackFrames API providing function arguments *only when allowed*; it's not a new security issue or a new burden on browser / VM implementers since they must already correctly implement security checks for the equivalent function.arguments API. [1] https://mail.mozilla.org/pipermail/es-discuss/2012-June/023247.html On Mon, Jun 11, 2012 at 12:57 PM, Brendan Eich bren...@mozilla.org wrote: Charles Kendrick wrote: On Sat, Jun 9, 2012 at 12:26 PM, Brendan Eichbren...@mozilla.org wrote: We do not want a non-debugger API that works only some of the time. What we want (IMO) is an API that allows runtime diagnostics to be collected. By necessity, function arguments would be unavailable for some stack frames. This is not a new situation or a flaw in the proposal, it's a situation which exists already for the function.arguments API. It seems to me we've lost the thread (maybe you haven't, but I have -- apologies for revisiting). I replied because of this flow: CK: Erik how do you reconcile this with the fact that this information can already be obtained in most production browsers via stack walking? EA: Stack walking is not available in strict functions CK: Interesting, but it doesn't speak against programmatic access to the call stack. At this point I'm not sure what you want -- object references to calling functions? You're right that we could disclose those where use strict does not poison function.arguments and arguments.callee already, but to what end? Erik's proposal was about standardizing a string-valued .stack property. If we can't have a common string-valued .stack property, we could still make a new one (.stackString or some such; yech) that doesn't include object references. Is there a strong motivation for sometimes exposing (where use strict allows) object references, or would your use-cases be met by some better string-valued spec? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Error stack
I have a sinking feeling it may be better to do just error.stackFrames, the new object/number/string lazy stack-trace reflection. We can model it on the union of error.stack implementations in the field, so those could be reimplemented under/on-top-of error.stackFrames. But we'll have no compatibility problems to sort out, and fewer complaints about the string-valued property (it may be fine to remain underspecified or unspecified). Your point about not violating use strict or elaborating too much is good, but I want to push back on one thing: local vars may be a bridge too far, especially with optimizing JITs, block-scoped let bindings, etc. Making arguments available is easier. Erik, what do you think? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Error stack
On Tue, Jun 12, 2012 at 7:12 AM, Brendan Eich bren...@mozilla.org wrote: Your point about not violating use strict or elaborating too much is good, but I want to push back on one thing: local vars may be a bridge too far, especially with optimizing JITs, block-scoped let bindings, etc. Making arguments available is easier. Revealing secrets passed in arguments? C'mon. Making arguments *generally* available would be fatal. That's why you need something like the getStack function I suggested earlier: debugging info is accessed only by rights amplification, and the amplifier is not made generally available. Erik, what do you think? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Error stack
Your point about not violating use strict or elaborating too much is good, but I want to push back on one thing: local vars may be a bridge too far, especially with optimizing JITs, block-scoped let bindings, etc. Making arguments available is easier. I definitely recognize that making local vars available is different-in-kind from making function arguments available. However I would ideally like to see it mentioned in the spec with recommended but not required wording. However what about receivers / this value? That seems to me to be more in the realm of function arguments, and reasonable to require. As I mentioned previously, this is available from Chrome's JavaScriptStackTrace API, but not for a function defined with use strict. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Error stack
On Tue, Jun 12, 2012 at 7:38 AM, Brendan Eich bren...@mozilla.org wrote: Also, as you pointed out, even error.stack leaks information. Where do you draw the line? Conservatively. I suggest that there be no error.stack, but rather getStack(error), in order to avoid this information leak. I think Charles was arguing that anyone keeping secrets would need use strict to protect those secrets anyway, because otherwise arguments.caller.arguments[i] (given non-strict caller and callee) can get them. Non-strict functions should not be assumed to be encapsulated, so it would be ok if they leaked info in yet more ways. However, a stack consists of a mixture of strict and non-strict activations, so I don't see how this helps. This is a good argument for Error.getStack(errObj), indeed. Not Error.getStack. Error is generally available, so if the amplifier were Error.getStack, it would be generally available too. This leaves open the question of where to get things that are not generally available. I hope and expect that we can find good answers in the module system. The getStack amplifier should be obtained by importing a module that is not generally importable. We've already encountered the need for such privileged imports... From http://wiki.ecmascript.org/doku.php?id=strawman:weak_references: Pending an accepted modules proposal, we do not yet specify in what namespace this constructor [makeWeakRef] is found. Note that makeWeakRef is not safe for general access since it grants access to the non-determinism inherent in observing garbage collection. The resulting side channel reveals information that may violate the confidentiality assumptions of other programs. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Error stack
On Mon, Jun 11, 2012 at 4:51 PM, Mark S. Miller erig...@google.com wrote: On Tue, Jun 12, 2012 at 7:38 AM, Brendan Eich bren...@mozilla.org wrote: I think Charles was arguing that anyone keeping secrets would need use strict to protect those secrets anyway, because otherwise arguments.caller.arguments[i] (given non-strict caller and callee) can get them. Non-strict functions should not be assumed to be encapsulated, so it would be ok if they leaked info in yet more ways. However, a stack consists of a mixture of strict and non-strict activations, so I don't see how this helps. It helps because, whether we are talking about a String API or an OO API, you make available arguments for non-strict functions, whereas for strict functions you do not. This doesn't expose any more information than is already exposed by function.arguments. This means a library using use strict and passing a secret to a non-strict function might have that secret revealed, and this is, again, already the case today (via function.arguments). This is a good argument for Error.getStack(errObj), indeed. Not Error.getStack. Error is generally available, so if the amplifier were Error.getStack, it would be generally available too. This leaves open the question of where to get things that are not generally available. I hope and expect that we can find good answers in the module system. The getStack amplifier should be obtained by importing a module that is not generally importable. We've already encountered the need for such privileged imports... I'm reading this as saying that stack traces in general should not be available unless the code is privileged in some way. This can't be what you mean, so could you clarify? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Error stack
On Mon, Jun 11, 2012 at 4:12 PM, Brendan Eich bren...@mozilla.org wrote: I have a sinking feeling it may be better to do just error.stackFrames, the new object/number/string lazy stack-trace reflection. We can model it on the union of error.stack implementations in the field, so those could be reimplemented under/on-top-of error.stackFrames. But we'll have no compatibility problems to sort out, and fewer complaints about the string-valued property (it may be fine to remain underspecified or unspecified). Your point about not violating use strict or elaborating too much is good, but I want to push back on one thing: local vars may be a bridge too far, especially with optimizing JITs, block-scoped let bindings, etc. Making arguments available is easier. Erik, what do you think? Yes, at this point I'm also convince that we should provide a new property that provides structured information of the stack trace and not specify Error stack at all. -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Error stack
On Tue, Jun 12, 2012 at 7:59 AM, Charles Kendrick char...@isomorphic.com wrote: I'm reading this as saying that stack traces in general should not be available unless the code is privileged in some way. This can't be what you mean, so could you clarify? That is exactly what I mean. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Error stack
Mark S. Miller wrote: On Tue, Jun 12, 2012 at 7:38 AM, Brendan Eichbren...@mozilla.org wrote: Also, as you pointed out, even error.stack leaks information. Where do you draw the line? Conservatively. I suggest that there be no error.stack, but rather getStack(error), in order to avoid this information leak. With some kind of import getStack from @reflect; or similar, and SES uses a custom loader to censor @reflect? I think Charles was arguing that anyone keeping secrets would need use strict to protect those secrets anyway, because otherwise arguments.caller.arguments[i] (given non-strict caller and callee) can get them. Non-strict functions should not be assumed to be encapsulated, so it would be ok if they leaked info in yet more ways. However, a stack consists of a mixture of strict and non-strict activations, so I don't see how this helps. I thought so too, but Charles is arguing both (a) no worse than today (not better than today); (b) useful for people who prefer non-strict code and a more useful stack-tracing API in the core language. This is a matter of preference, not necessity, if we're talking about the language as it is. We won't be making use strict the default. We are trying to avoid more modes (1JS). We're not talking about SES. So I don't see how it can be argued logically that a non-strict-only arguments-disclosing stack-tracing API is either never helpful nor always helpful. YMMV. This is a good argument for Error.getStack(errObj), indeed. Not Error.getStack. Error is generally available, so if the amplifier were Error.getStack, it would be generally available too. This leaves open the question of where to get things that are not generally available. I hope and expect that we can find good answers in the module system. The getStack amplifier should be obtained by importing a module that is not generally importable. We've already encountered the need for such privileged imports... Fromhttp://wiki.ecmascript.org/doku.php?id=strawman:weak_references: Pending an accepted modules proposal, we do not yet specify in what namespace this constructor [makeWeakRef] is found. Note that makeWeakRef is not safe for general access since it grants access to the non-determinism inherent in observing garbage collection. The resulting side channel reveals information that may violate the confidentiality assumptions of other programs. I see -- thanks. We should try to detail the privileged APIs and their module(s) a bit more. I used @reflect above but I didn't mean to equate it to Tom's Reflect.* used in conjunction with direct proxies. And not all reflection facilities are privileged -- more the reverse for the direct proxy stuff, right? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Error stack
On Mon, Jun 11, 2012 at 5:55 PM, Mark S. Miller erig...@google.com wrote: On Tue, Jun 12, 2012 at 7:59 AM, Charles Kendrick char...@isomorphic.com wrote: I'm reading this as saying that stack traces in general should not be available unless the code is privileged in some way. This can't be what you mean, so could you clarify? That is exactly what I mean. The only way I can see this working is if there is a way for a given piece of code to trap an error and ask some kind of (elevated privilege) logging system to provide diagnostic information that a (privileged) end user can see. It also seems like, in addition to this, you should be able to get to stack information programmatically so long as you stay within your module or modules that have the same privilege. This doesn't sound like something that could be reasonably standardized into ECMAScript in the near future, and, without all those pieces in place, it doesn't seem like ECMAScript should just disallow the ability to get stack traces. Brendan brought up SES - I know little about it, but for its sake I hope this critical use case is taken into account. On Mon, Jun 11, 2012 at 6:17 PM, Brendan Eich bren...@mozilla.org wrote: I thought so too, but Charles is arguing both (a) no worse than today (not better than today); (b) useful for people who prefer non-strict code and a more useful stack-tracing API in the core language. Just to clarify, I prefer *some* of the ideas behind use strict and in fact we built a subset of use strict into our in-house tools long before JSLint existed. But if it's going to impose a security boundary between my own methods and reduce the utility of stack traces which are sometimes the only thing you have to go on.. no thank you. That seems to me to conflate useful error checking and security; there is overlap, but not 100% overlap by any means. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Error stack
2012/6/12 Brendan Eich bren...@mozilla.org I see -- thanks. We should try to detail the privileged APIs and their module(s) a bit more. I used @reflect above but I didn't mean to equate it to Tom's Reflect.* used in conjunction with direct proxies. And not all reflection facilities are privileged -- more the reverse for the direct proxy stuff, right? That's right. The reflection API specced at http://wiki.ecmascript.org/doku.php?id=harmony:reflect_api was meant to encapsulate both proxies and all the utility methods that a proxy handler needs to uniformly forward trapped ops to a target object. AFAICT, none of these operations are privileged: it's easy enough to define them in terms of more primitive, immediately available JS built-ins/operators. Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
