Re: Fixing instanceof (Array.isArray() etc.)?

> with postMessage and other standard/secure ways to pass data around the cross > frame problem is slowly disappearing unless it's meant to sandbox the Array, > as example, of that frame. > > A classic example is indeed the freedom to extend the way we like a sandboxed > Array which hopefully w

Re: Fixing instanceof (Array.isArray() etc.)?

Duck typing is an interesting consideration. If one could express x follows ArraySpec then that would work for both array-like objects and Array instances from other frames. On Jan 20, 2012, at 19:28 , Herby Vojčík wrote: > Inspired by Smalltalk messages like #isInteger (defined in Object

Re: Shouldn't timers be specified?

Sorry to spam this thread but I wanted to get the relevent points in up front: 'Actually, wait a minute -- I think I disagree with you here. WHATWG specifies the specific event queue of the browser. Node.js has its own event queue. Others may as well. The unofficial agreement of JS has always been

Re: Shouldn't timers be specified?

Absolutely agree. I don't see a place for Node's 1ms resolution in browsers, which was the impetus for raising the issue. I see a place for Node (and other non-browser platforms) to implement their own host timers that provide higher resolution (In fact Node's process.nextTick(callback) is a good e

Re: Shouldn't timers be specified?

Brandon Benvie January 21, 2012 7:37 PM Correction: it is specified in HTML5 here http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#timers. Suffice to say that a DOM specification isn't sufficient for something so central to JavaScript,

Re: Shouldn't timers be specified?

Correction: it is specified in HTML5 here http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#timers . Suffice to say that a DOM specification isn't sufficient for something so central to JavaScript, nor is it the specification currently followed by browsers anyway. ___

Shouldn't timers be specified?

I just finished answering this question on StackOverflow and it got me thinking about the obvious: timers are not specified yet are central to a vast swath of JavaScript code. Timers in Node.js have a significantly higher resolution than what is found in browsers: `setTimeout(fn, 1)` will, in fact,

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Brendan Eich January 21, 2012 4:39 PM Er, const, I hope -- not let. Right? And _the_real_foo should be expanded: { private foo; ... } desugars to { const foo = Name.create("foo"); ... } with Name.create imported appropriately. /be __

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Herby Vojčík January 21, 2012 2:21 PM Oh. I favor 1. Inspired by latest notes and for(let...) I would see { private foo; ... } desugared to { let foo = _the_real_foo; Er, const, I hope -- not let. Right? /be ___

Re: Block lambda is cool, its syntax isn't

>From a web development perspective, the small cost of a string literal "use fn"; in trade for the reduced bytes of "fn" would be well received. I recently delivered a fairly large scale mobile web application, to a Bocoup client, that had 340 occurrences of "function" (that includes all library a

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Brendan Eich wrote: Herby Vojčík January 21, 2012 1:56 PM Brendan Eich wrote: private foo; @foo = bar; // this-relative private foo return @foo === other.@foo; return {@foo: bar}; This helps a lot, but there still _is_ an identifier foo having that private name in

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Herby Vojčík January 21, 2012 1:56 PM Brendan Eich wrote: Herby Vojčík January 21, 2012 1:33 PM Brendan Eich wrote: http://wiki.ecmascript.org/doku.php?id=strawman:private_names#private_declarations_exist_in_a_separate_name_space_parallel_to_the

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Brendan Eich wrote: Herby Vojčík January 21, 2012 1:33 PM Brendan Eich wrote: http://wiki.ecmascript.org/doku.php?id=strawman:private_names#private_declarations_exist_in_a_separate_name_space_parallel_to_the_variable_binding_environment The last really was too much for

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Herby Vojčík January 21, 2012 1:33 PM Brendan Eich wrote: This was already proposed. See the whole strawman, but in particular these sections: http://wiki.ecmascript.org/doku.php?id=strawman:private_names#the_private_declaration http://wiki.ecmascript.org/doku.php?i

Re: Block lambda is cool, its syntax isn't

François REMY January 21, 2012 1:00 PM -Message d'origine- From: Brendan Eich > François REMY > January 21, 2012 1:34 AM > About the 'fn' proposal, I'm happy with it. Asking a 'use' statement > just for that feature ma

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Brendan Eich wrote: This was already proposed. See the whole strawman, but in particular these sections: http://wiki.ecmascript.org/doku.php?id=strawman:private_names#the_private_declaration http://wiki.ecmascript.org/doku.php?id=strawman:private_names#private_declaration_scoping http://wiki.e

Re: Block lambda is cool, its syntax isn't

-Message d'origine- From: Brendan Eich > François REMY > January 21, 2012 1:34 AM > About the 'fn' proposal, I'm happy with it. Asking a 'use' statement > just for that feature may prove a little excessive but if it can be > merged with other can-be-br

Re: Block lambda is cool, its syntax isn't

Jorge January 21, 2012 12:14 PM On 21/01/2012, at 05:31, Brendan Eich wrote: We are not going to use non-ASCII characters, so you are still barking up the wrong tree. Aren't you discussing the possibility of using ƒ or λ for functions in this same thread ? N

Re: Block lambda is cool, its syntax isn't

On 21/01/2012, at 05:31, Brendan Eich wrote: >> Jorge >> January 20, 2012 7:15 PM >> >> Sorry, I don't follow, with "that" you mean "something else" or "the acute >> accent" ? > > Oh, not ' but the diacritical on é, you mean? Yes, the acute accent. For example.

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

This was already proposed. See the whole strawman, but in particular these sections: http://wiki.ecmascript.org/doku.php?id=strawman:private_names#the_private_declaration http://wiki.ecmascript.org/doku.php?id=strawman:private_names#private_declaration_scoping http://wiki.ecmascript.org/doku.php

<| and function declarations

Hello, there is possibility to use <| with function expressions: SuperFun <| function Fun () { ... } and it creates parallel constructor and prototype chaining. Would it be possible to allow: function SuperFun <| Fun () { ... } to use <| in function _declarations_ as well? For sim

__proto__ security

Hi, This is an attempt to list and discuss how threats of a mutable __proto__ can be prevented and how it is different in the data and accessor property cases. ## One frame Assuming code from 2 parties are running in the same "frame" (one set of built-ins) - var o = Object.create(Object.fre

shortcuts for defining block-local private names, plays nicely with @foo syntax

Hello, since @-prefixed syntax to access private-named properties seems to win in the private grounds (and it is good thing), I'd like kill two birds with one stone: - private keyword seemed to lose its role - to access property via @foo, I must 'let foo = Name.create()' first So let us all

Re: Block lambda is cool, its syntax isn't

François REMY January 21, 2012 1:34 AM About the 'fn' proposal, I'm happy with it. Asking a 'use' statement just for that feature may prove a little excessive but if it can be merged with other can-be-breaking syntax reforms ('use es6') Please read the notes

Re: Block lambda is cool, its syntax isn't

François REMY January 21, 2012 1:47 AM (sorry, last mail was sent by mistake) You sent your reply twice, to this thread and another. I replied to the other. As a plus, it allows a very powerful optimisation (block-lambda running in the same frame as the fun

Re: Block lambda is cool, its syntax isn't

François REMY January 21, 2012 2:14 AM function a(x) { let count=0; let arr = [...]; let $lambda = { [Call]: {|| ... } }; arr.forEach($lambda); $lambda.[Call] = function() { throw new InvalidTargetException(); } No

Re: The global object as the "global scope instance object"

On Jan 21, 2012, at 12:25 AM, Andreas Rossberg wrote: > On 21 January 2012 01:23, Allen Wirfs-Brock wrote: >> Temporal dead-zone initialization tracking requires extra state and checking >> (except for the common cases within functions where it can be statically >> determined that there are no p

Re: Fixing instanceof (Array.isArray() etc.)?

with postMessage and other standard/secure ways to pass data around the cross frame problem is slowly disappearing unless it's meant to sandbox the Array, as example, of that frame. A classic example is indeed the freedom to extend the way we like a sandboxed Array which hopefully will never inter

Re: Block lambda is cool, its syntax isn't

Great stuff. I’m equally intrigued by the `use fn` pragma: It allows one to selectively break compatibility. Caveat: This kind of pragma introduces a lot of new complexity. Pragmas would indeed become less burdensome if one could configure them on a per-project basis. It corresponds to Eclipse

Re: Block lambda is cool, its syntax isn't

(sorry, last mail was sent by mistake) This seems pretty easy to enforce to me. function a(x) { let count = 0; let arr = [ (x+1)^(x-1), (x*x), (2*x-1) ]; arr.forEach({|x| if((x&1)==0) count++; }); return count; } can be compiled as : function a(

Re: Block lambda is cool, its syntax isn't

I think "use fn;" (real pragma syntax), with the low-precedence assignment-expression fn (params) assign-expr production, wins. What do you think? Having fn would be sweet. For many kinds of pragmas, it would be great if one could configure these per project (or per directory). Then one could

Re: Block lambda is cool, its syntax isn't

François REMY wrote: About the 'fn' proposal, I'm happy with it. Asking a 'use' statement just for that feature may prove a little excessive but if it can be merged with other can-be-breaking syntax reforms ('use es6'), why not. But, seriously, what really makes it impossible to use # or @? Tho

Re: Block lambda is cool, its syntax isn't

(sorry, last mail was sent by mistake) This seems pretty easy to enforce to me. function a(x) { let count = 0; let arr = [ (x+1)^(x-1), (x*x), (2*x-1) ] arr.forEach({|x| if((x&1)==0) count++; }); return count; } can be compiled as : function a(x

Re: Block lambda is cool, its syntax isn't

This seems pretty easy to enforce to me. function a(x) { let count = 0; [ (x+1)^(x-1), (x*x), (2*x-1) ]; arr.forEach({|x| if((x&1)==0) count++; }); return count; } -Message d'origine- From: Brendan Eich Sent: Saturday, January 21, 201

Re: Block lambda is cool, its syntax isn't

About 'ƒ': on my keyboard, there's no way to type it. I have to use ALT+its UTF8 keycode, and it doesn't work in all programs. BTW, since the default file format on Windows is not UTF8, expect many developers to use ISO-8859-1 for their JS files. Personnaly, I use Notepad++ which allow me to use

Re: The global object as the "global scope instance object"

On 21 January 2012 01:23, Allen Wirfs-Brock wrote: > Temporal dead-zone initialization tracking requires extra state and checking > (except for the common cases within functions where it can be statically > determined that there are no possible references within the dead zone). >  This additional