Re: let/const in switch cases

On Aug 14, 2012, at 5:05 AM, Andreas Rossberg wrote: > On 10 August 2012 05:48, Brendan Eich wrote: >> Luke Hoban wrote: >>> Current Chrome builds appear to follow this approach, reporting that >>> the 'let' in the initial code sample above appears in an 'unprotected >>> statement context'. >>

Re: Feedback on hypot and hypot2

On Aug 15, 2012, at 5:09 PM, David Bruant wrote: > Le 14/08/2012 04:16, Allen Wirfs-Brock a écrit : >> check out the current ES66 spec. draft. Based upon discussions at the >> March TC39 meeting hypot2 was eliminated and an optional third >> argument as added to hypot. &g

new strawman: syntactic support for private names

The strawman is at http://wiki.ecmascript.org/doku.php?id=strawman:syntactic_support_for_private_names Allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: new strawman: syntactic support for private names

object value of @name obj[@name] would do a @elementSet/@elementGet using the name object value of @name. Allen > > [1] http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation > > On Aug 29, 2012, at 1:04 , Allen Wirfs-Brock wrote: > >> The s

Re: new strawman: syntactic support for private names

On Aug 29, 2012, at 4:28 AM, Herby Vojčík wrote: > Yes, I also would like to know why this simpler older model was not good > enough. See my reply to Axel. If you are referring to a simpler older model using the @ sigil, note that we don't actually have one. As far as I'm aware, this is the

Re: new strawman: syntactic support for private names

On Aug 31, 2012, at 12:53 AM, Andreas Rossberg wrote: > On 29 August 2012 18:39, Allen Wirfs-Brock wrote: >> There are been various previous runs at defining syntactic support for using >> unique/private names. They all run into either real or hypothetical >> usabilit

Re: iterate and enumerate trap signature inconsistency

On Sep 2, 2012, at 11:13 AM, David Bruant wrote: > Hi, > > The enumerate (for..in loops) and iterate (for..of loops) traps have > inconsistent signatures. The former needs an array of strings to be > returns, the latter an iterator. the current ES6 spec. draft uses internal methods, [[Enumerate

System Module and/or Object???

Do we have an active champion for such a module or global object? There is a strawman[1] that is pretty sketchy. There is also a proposal [2] for a @std modules that alias most of the built-ins with global names. Neither of them describe any new functionality that is only available through t

Re: Annex A of 5th Edition

On Sep 6, 2012, at 12:17 PM, Joseph Spencer wrote: > My apologies on that one. I meant to type the following: > > PostfixExpression: > LeftHandSideExpression [no LineTerminator here] ++ > LeftHandSideExpression [no LineTerminator here] -- > > PrefixExpression: > ++ [no LineTerminat

Re: Annex A of 5th Edition

On Sep 6, 2012, at 4:35 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >>> >>> >> >> According to the specification, those all should produce runtime >> ReferenceError exceptions. However, at least Firefox, reports them as early >>

Re: Annex A of 5th Edition

On Sep 6, 2012, at 10:19 PM, Joseph Spencer wrote: > Would it not be beneficial to bring Annex A into greater conformity with > the rest of the spec at this point? > > Such changes seem relatively safe (to a noobie that is ;), as any code > produced moving forward by devs would still parse jus

Re: Annex A of 5th Edition

another problem with your grammar is that that NumericLiterals need to be Referable. For example the following is valid ES code: 0.0.toLocaleString() But these are just details that could be fixed. There are many grammars that describe any language and creating one is a design activity tha

Generator issue: exceptions while initializing arguments

This is the first of probably several semantic issues WRT generator that will need to be resolved in the spec. Here is the user level issue: let thrower = {throw () {throw "exception"}}; function * G(arg = thrower.throw()) { //possibly other explicit initialization code which could also throw

Re: Generator issue: exceptions while initializing arguments

On Sep 8, 2012, at 3:20 PM, Brendan Eich wrote: > SpiderMonkey (Firefox 15 and newer has default parameters): > > js> function f(a = g) { function g(){}; return a; } > js> f() > function g(){} > > So function g is hoisted and a defaults to it, as expected. While I agree that the above is reaso

Re: Generator issue: exceptions while initializing arguments

On Sep 8, 2012, at 3:51 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> On Sep 8, 2012, at 3:20 PM, Brendan Eich wrote: >> >>> SpiderMonkey (Firefox 15 and newer has default parameters): >>> >>> js> function f(a = g) { function g

Re: Generator issue: exceptions while initializing arguments

On Sep 8, 2012, at 3:59 PM, Brendan Eich wrote: > Here's an attempt at a crucial experiment: > > js> var g = 'now' > js> function f(a = g) { yield a; } > js> var it = f() > js> g = 'later' > "later" > js> it.next() > "later" > > So I'm wrong, SpiderMonkey inserts the impliciti |yield;| before p

Re: Generator issue: exceptions while initializing arguments

On Sep 8, 2012, at 5:11 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> On Sep 8, 2012, at 3:51 PM, Brendan Eich wrote: >>> Allen Wirfs-Brock wrote: >>>> On Sep 8, 2012, at 3:20 PM, Brendan Eich wrote: >>>> >>>>> SpiderMonkey (Fire

Re: Generator issue: exceptions while initializing arguments

On Sep 8, 2012, at 5:20 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> On Sep 8, 2012, at 3:59 PM, Brendan Eich wrote: >> >>> Here's an attempt at a crucial experiment: >>> >>> js> var g = 'now' >>> js>

Re: Generator issue: exceptions while initializing arguments

On Sep 9, 2012, at 3:32 PM, Brendan Eich wrote: > I wanted to leave a clean example (no var and let mixing, either): > > function dataSnapshot(aCollection) { > let snapshot = aCollection.clone(); > let i = 0; > return { >next: function () { > if (i == snapshot.length) >throw

A syntax alternative for generators (was: Generator issue: exceptions while initializing arguments)

The initializing generator arguments thread and related discussions has got me questioning our use of function declaration/expression syntax as our basis for defining generators. Changing this would be a departure from what Firefox has supported in recent years, but in ES6 we have more construc

Re: A syntax alternative for generators (was: Generator issue: exceptions while initializing arguments)

On Sep 11, 2012, at 7:48 PM, Jason Orendorff wrote: > I'd appreciate a less contrived motivating example. The best way to > implement this dataSnapshot() function is simply: > >function dataSnapshot(aCollection) { >return aCollection.clone(); >} > > -j > My original example

Re: A syntax alternative for generators (was: Generator issue: exceptions while initializing arguments)

oops, I forgot to force calls to the inner function * definitions. Another hazard of the plan of record that my alternative proposal doesn't have. I fixed occurrence of this bug below: On Sep 11, 2012, at 9:42 PM, Allen Wirfs-Brock wrote: > > On Sep 11, 2012, at 7:48 PM, Jaso

Re: Performance concern with let/const

some comments below On Sep 16, 2012, at 9:35 PM, Luke Hoban wrote: > We've begun deeper investigations of implementation practicalities related to > let/const, and two significant performance concerns have been raised. I > think these both merit re-opening discussion of two aspects of the let/

Re: Performance concern with let/const

On Sep 17, 2012, at 12:37 PM, Luke Hoban wrote: > > These are good questions. Paul will be attending the TC39 meeting this week, > and can likely talk to specific details. High level though, we statically > eliminate the TDZ checks for references to 'let' within the same closure body > as

Re: Performance concern with let/const

On Sep 18, 2012, at 7:27 AM, Andreas Rossberg wrote: > On 17 September 2012 19:51, Allen Wirfs-Brock wrote: >> >> On Sep 17, 2012, at 12:37 PM, Luke Hoban wrote: >>> >>> These are good questions. Paul will be attending the TC39 meeting this >>> wee

Re: About bugfix: For ISO 8601 syntax, Date.parse should accept " " in places where "T" is allowed

This is the response I posted to the bugzilla issue: I would like to see a better motivation present for why this change is important. In particular, it is a deviation from the ECMAScript standard. While syntactic extensions to the Date.parse syntax is allowed by the specification. It is not

Re: Array comprehension syntax

On Sep 21, 2012, at 4:32 PM, Jason Orendorff wrote: > ... > > 2. These comprehensions are permitted: >[EXPR for x of obj if a, b, c] >[EXPR for x of obj if x = 3] > >The first is surprising to me for two reasons: first, because >commas in an array literal usually separa

Re: Array comprehension syntax

On Sep 21, 2012, at 4:32 PM, Jason Orendorff wrote: > I have a few proposals and questions about ES6 array comprehensions: > http://people.mozilla.org/~jorendorff/es6-draft.html#sec-11.1.4.2 > > 1. It seems simpler and more general to accept arbitrary sequences >of 'for' and 'if' clauses: >

Re: Array comprehension syntax

On Sep 22, 2012, at 10:39 AM, Brendan Eich wrote: > Jason Orendorff wrote: >> ... > > Yeah, not as strong a precedent -- we should treat JS as big brother here, > over time. > >> I actually kind of like Allen's argument about not wanting to >> encourage the use of array comprehensions for comp

Re: Array comprehension syntax

On Sep 22, 2012, at 2:52 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> >>> My personal bias, is that comprehensions are just sugar that are best used >>> to express relatively simple and common construction use cases. >>> Complicated sequences of |

Re: Optional argument types

On Sep 24, 2012, at 11:13 AM, Rick Waldron wrote: > ... > Check these out: > > http://wiki.ecmascript.org/doku.php?id=strawman:guards > http://wiki.ecmascript.org/doku.php?id=strawman:trademarks > > Rick But, getting back to Dmitry's original question. These haven't been accepted as proposa

Re: Nannying (was: Array comprehension syntax)

On Sep 24, 2012, at 10:37 AM, Jason Orendorff wrote: > I want to defend my kind of nannying. :-) > > I favor rejecting `if x = y` in comprehensions because it's almost > always going to be a bug, and a tough bug to diagnose. Mistaken > assumptions tend to stay invisible for a long time. The m

Re: Optional argument types

ithoutType = 'yes'; > > function optType(HTMLElement|String domEl, withoutType='again') { > // Nice lang :) > } > > But this is only noise... :) > > > > > 2012/9/24 Dmitry Soshnikov > > > On Mon, Sep 24, 2012 at 11:26 AM, Allen W

Re: Nannying (was: Array comprehension syntax)

On Sep 24, 2012, at 9:00 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> The argument could validly be made for IfStatement which we cannot change, >> for compatibility reasons. To me, if is probably mostly an issue of whether >> we want consistency be

Re: Nannying (was: Array comprehension syntax)

On Sep 25, 2012, at 1:30 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> I think we should go the all AssignmentExpression route. It avoid >> ArrayLiteral-like comma confusion in all three positions. It is also a >> simpler set of rules to teach and remember. >

Re: Nannying (was: Array comprehension syntax)

On Sep 25, 2012, at 1:27 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> I note that in your toy grammar you avoid the comma issue at the front and >> in the for clauses by using AssignmentExpression in those positions. >> >> The current ES6 spec. draft has

Re: Nannying (was: Array comprehension syntax)

On Sep 26, 2012, at 6:22 AM, Andreas Rossberg wrote: > On 26 September 2012 15:02, Brendan Eich wrote: >> Let's agree that AssignmentExpression is ok (required for the left-most >> comprehension expression). The main nannying objection was to trying to ban >> = at top level of if and for heads.

repeated parameter names and default values

Consider function f(a, b=a, a=3, c=a) { return a+" "+b+" "+c } console.log(f(1)); Based upon the conclusions about argument binding at the recent TC39 meeting this will display: "3 1 3" Any disagreement of this? Allen ___ es-discuss

Re: repeated parameter names and default values

On Sep 27, 2012, at 9:31 AM, Andrea Giammarchi wrote: > it would be stupid to code like that but it makes sense since it has > basically always been like that :) A big part of of my job is specifying what stupid code does. Allen ___ es-discuss mail

Re: repeated parameter names and default values

Another: The notes from last week's meeting said WRT function parameter bindings: Conclusion/Resolution - `var` bindings and are in scope within the function - cannot use `let` to shadow a parameter - defaults can refer to any top level binding Using the above guidance, consider this one: funct

Re: repeated parameter names and default values

On Sep 27, 2012, at 10:03 AM, Oliver Hunt wrote: > > On Sep 27, 2012, at 9:45 AM, David Bruant wrote: > >> ...this is how I discovered that, in non-strict mode, it's possible to >> define a function where 2 arguments have the same name... >> >> Le 27/09

Re: repeated parameter names and default values

On Sep 27, 2012, at 9:45 AM, David Bruant wrote: > ... > Also, is there really a value in being able reuse a previous argument to > define the value of another argument? > The idea of "for the second argument, use its value unless it's > undefined in which case, reuse the value of the first argume

Re: repeated parameter names and default values

On Sep 27, 2012, at 10:09 AM, Jason Orendorff wrote: > On Thu, Sep 27, 2012 at 11:19 AM, Allen Wirfs-Brock > wrote: >> function f(a, b=a, a=3, c=a) { >> return a+" "+b+" "+c >> } >> console.log(f(1)); >> >> Based upon the

Re: repeated parameter names and default values

On Sep 27, 2012, at 10:26 AM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> My original intent was to apply such rules and the current spec. draft >> actually has some of these restrictions. However, those parts were written >> before 1JS emerged and the consensus a

a new ES6 spec. draft dis available

As usual, at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts Changes include: Significant reworking of the use of cover grammars for unambiguously defining assignment restructuring patterns and for arrow function formal parameters. Renaming of Quasis to Template Strings Inco

Re: a new ES6 spec. draft dis available

Nothing new in this section in this draft and what is there will eventually get a significant rewrite... On Sep 27, 2012, at 9:32 PM, Axel Rauschmayer wrote: > B.3.1, “The __proto__ pseudo property” will eventually be moved out of the > annex, right? > > If I may: I have two questions about t

Re: repeated parameter names and default values

On Sep 27, 2012, at 1:40 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> ... > >> I'm all for statically disallowing many of these "stupid" cases and I >> think it is fine to do the checks at "first call" rather than load-time (a >

Re: repeated parameter names and default values

On Sep 28, 2012, at 7:58 AM, John Lenz wrote: > > > On Thu, Sep 27, 2012 at 10:12 AM, Allen Wirfs-Brock > wrote: > Another: > > The notes from last week's meeting said WRT function parameter bindings: > > Conclusion/Resolution > - `var` bindings a

Re: Object.prototype.__proto__

On Sep 28, 2012, at 8:00 AM, Axel Rauschmayer wrote: >>> It is my understanding of B.3.1 that Object.prototype.__proto__’s only use >>> is as a flag to switch off __proto__ for all objects (I’m assuming in >>> settings similar to Caja). Wouldn’t it be better to introduce a real >>> boolean fla

Re: Early error vs. error on first call to function vs. runtime error

On Sep 27, 2012, at 10:54 PM, Brendan Eich wrote: > Oliver Hunt wrote: >> I'm generally against error on first call -- in the general case if you're >> able to determine a function should fail on first execution you can >> determine that it could fail during parsing and semantic analysis. > >

Re: Early error vs. error on first call to function vs. runtime error

On Sep 28, 2012, at 9:54 AM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> I see a potential benefit to implementor in the "deferred early error" >> concept and there are implementation alternatives that would be lost without >> it. I see a minor negative im

Re: repeated parameter names and default values

On Sep 28, 2012, at 9:16 AM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> I generally use "static" to mean: solely based upon analysis of the program >> text without any dependencies upon runtime state. That's my criteria for >> classifying someth

Re: repeated parameter names and default values

On Sep 28, 2012, at 11:23 AM, Brendan Eich wrote: > > We do! Where's the list of candidate early error cases? Cc'ing Luke. Within recent ES6 drafts, all early errors are identified within subsections labeled: "Static Semantics: Early Errors" The easiest way to see all of them is just to do a

Re: ES6 spec: [[Home]] and HomeObject versus [[MethodName]] and MethodName

feel free to file a bug On Sep 28, 2012, at 1:07 PM, Axel Rauschmayer wrote: > In method environment records, you have HomeObject and MethodName, whereas > function objects have the properties [[Home]] and [[MethodName]]. This is > really just a minor nitpick, but it might make sense to rename

Re: Why TypeArray instead of TypedArray?

certainly a bug, and one that in this case was propagated from the wiki page. As stated in the change notes, the binary data material in Rev10 is just place holder material copied from the Wiki. It isn't yet at all definitive and it would be a waste to spend very much time reviewing it. Allen

Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

As I noted in another thread, the binary data material is very preliminary and and you shouldn't read too much significance into things like this relating to that material. However, there is a bigger issue here. You could have asked a similar question about Map.prototype. Why isn't Map.proto

Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

On Sep 29, 2012, at 4:20 PM, Yusuke Suzuki wrote: > Thanks for your reply. > > Why did I do this? Because, we are defining a significant number new > built-in "classes" and it is going to be increasingly hard to define > meaningful instance state for all such prototypes. It is also arguably

Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

On Sep 29, 2012, at 5:17 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> However, there is a bigger issue here. You could have asked a similar >> question about Map.prototype. Why isn't Map.prototype a Map instances? Is >> this a bug or an i

Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

On Sep 29, 2012, at 7:23 PM, Rick Waldron wrote: > ... > > Subjectively, the examples here are exactly how I would expect (hope?) this > to behave, as the existing behaviour: > > > Array.prototype.push(1) > 1 > > Array.prototype > [ 1 ] > > > ...Has always been seemed "strange" ;) > I bel

Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

On Sep 29, 2012, at 7:26 PM, Rick Waldron wrote: > > > On Sat, Sep 29, 2012 at 6:19 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: > My intention, subject to feedback here and from TC39, is to follow the > pattern I used for Map as much as possible. However, Typ

Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

On Sep 29, 2012, at 11:11 PM, Brendan Eich wrote: > Mark S. Miller wrote: >> On Sat, Sep 29, 2012 at 10:21 PM, Mark S. Miller > > wrote: >> >> >>I agree that the only security issue is avoiding the >>communications channel. >> >>Security aside, given maxi

Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

On Sep 30, 2012, at 9:47 AM, Brendan Eich wrote: > Brendan Eich wrote: >> The main thing I missed there is the prefixing of "~" on any tag naming a >> core language built-in constructor. What's this for? Why not for DOM >> built-ins too? > > This step: > > v. If tag is any of "Arguments", "Ar

Re: iterator as a unique name and the enumerate trap

On Oct 1, 2012, at 6:56 AM, David Bruant wrote: > 2012/10/1 Tom Van Cutsem > 2012/10/1 Tom Van Cutsem > If yes, then we should ask ourselves the question: is this a useful hook for > regular objects to customize? I think it's not, really (bear in mind that > enumeration can only generate stri

Re: a new ES6 spec. draft dis available

On Oct 1, 2012, at 8:34 AM, Tom Van Cutsem wrote: > - The Handler Constructor (as per > , defining > a useful "default proxy handler" that programmers can subclass) I think I'm going to trying to fit all the moving parts of the

Re: a new ES6 spec. draft dis available

On Oct 1, 2012, at 10:06 AM, Tom Van Cutsem wrote: > 2012/10/1 Allen Wirfs-Brock > > I think I'm going to trying to fit all the moving parts of the Proxy > mechanism (other than the more general Reflect module) into a single > subsection of chapter 15. > > That ma

Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

On Oct 1, 2012, at 12:21 PM, Brendan Eich wrote: ... > The best reason for using Object is the one Mark raised: class (as sugar for > constructor/prototype) uses Object. > > But if you've read the thread this far, my objective is not to enforce one > implementation approach or the other. It's t

Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

On Oct 1, 2012, at 12:39 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> Line 5.c.v is dealing with the ES5 requirement that "host objects" not reuse >> the listed [[Class]] values for anything other than the specified built-ins. >> This version of toSt

Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

On Oct 1, 2012, at 2:44 PM, Norbert Lindenberg wrote: > It might be useful to list all the observable features to which "valid > instance of" might lead for a built-in BuiltIn.prototype, and check whether > we want them for new built-ins: > > 1) Object.prototype.toString.call(BuiltIn.prototype

Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

On Oct 1, 2012, at 3:48 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >>> >>> >> >> Let me try explaining this again, > > No need to rehash. > > Responding to my point about other legacy "tag tests" that are not twiddled > w

Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

On Oct 1, 2012, at 9:02 PM, Brendan Eich wrote: > Mark S. Miller wrote: >> On Mon, Oct 1, 2012 at 8:17 PM, Brendan Eich > > wrote: >> >>Mark S. Miller wrote: >> >>Regarding the integrity of original >>Object.prototype.toString.call as a branding m

Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

On Oct 1, 2012, at 9:56 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> We can try to tell ES implementors that they must do certain things in order >> to be in conformance but that really doesn't work for code written by users >> of the language. > &g

Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

On Oct 1, 2012, at 4:08 PM, Domenic Denicola wrote: > On Oct 1, 2012, at 18:58, "Brendan Eich" wrote: > >> I am warming up to the way CoffeeScript does things -- not the translation >> scheme, __extends, __super__ -- rather, the plain Object instance created as >> C.prototype that has B.proto

Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

On Oct 1, 2012, at 10:37 PM, Brendan Eich wrote: > Brendan Eich wrote: >> But if we have a solid branding mechanism (like Domado's ideal in latest >> browsers? ;-) then that should be used universally and this becomes a >> don't-care. > > Just to be crystal clear: > > * in pre-ES6 browsers,

Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

On Oct 2, 2012, at 10:18 AM, Kevin Smith wrote: > > private @FooBrand; > class Foo { >constructor() { > /* establish the internal Fooness of the instance */ > this.@FooBrand = true; >} > } > Foo.isFoo = function (obj) {return !!obj.@FooBrand}; > > Using this strategy, wi

Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

On Oct 2, 2012, at 10:47 AM, Mark S. Miller wrote: > Having isFoo succeed on an instance of Bar is correct. But there's another > case that's more worrisome: > > Foo foo = new Foo(); > Baz baz = Object.create(foo); > > By Allen's pattern, isFoo will also succeed on an instance of baz. OTOH, we

Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

On Oct 2, 2012, at 10:52 AM, Herby Vojčík wrote: > > > Allen Wirfs-Brock wrote: >> >> If you really need to strongly tie instantiation with branding you >> probably have to use a factory function: >> >> module Fooishness { >>e

Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

On Oct 2, 2012, at 1:08 PM, Kevin Smith wrote: > > On the other hand, if you have many instances that need to be branded I > suspect that the distributed symbol based technique is going to have a better > performance profile than the WeakMaps. > > Is this true? Are there performance "caveat

Re: Suggestions for Set

On Oct 2, 2012, at 2:43 PM, Mark S. Miller wrote: > > > On Tue, Oct 2, 2012 at 2:18 PM, Rick Waldron wrote: > > The direct reasoning for the resolution was: > > "Cannot be both iterable and array-like" > > It's possible that this could be added to the agenda for november, if Brendan > want

Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

On Oct 2, 2012, at 2:46 PM, Mark S. Miller wrote: > > > On Tue, Oct 2, 2012 at 11:01 AM, Allen Wirfs-Brock > wrote: > > On Oct 2, 2012, at 10:18 AM, Kevin Smith wrote: > >> >> private @FooBrand; >> class Foo { >>constructor() { >&g

Re: Suggestions for Set

On Oct 2, 2012, at 3:55 PM, Brendan Eich wrote: > Domenic Denicola wrote: >> From: Rick Waldron [mailto:waldron.r...@gmail.com] >> This seems like an unfortunate decision, and I couldn't discern the motivation in the minutes. When would I want to use a syntax that fails for iter

Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

On Oct 2, 2012, at 9:46 PM, Brendan Eich wrote: > At this point I'd go with "Object" (IOW, _stet_), unless Allen has a thought. I agree. Regarding 3, if it is easy spec-wide to make the prototype non-instances that would be preferable, but as long as the per instance state in the prototype is

Re: Suggestions for Set

A couple observations: 1) this whole issue is only relevant if you actually have array objects containing holes. Special treat for sparse arrays doesn't hurt anybody (other than implementors) who doesn't use them. 2) If we (and the broader developer community) don't like sparse behavior for

Re: Suggestions for Set

On Oct 3, 2012, at 7:47 AM, Erik Arvidsson wrote: > On Wed, Oct 3, 2012 at 3:24 AM, Andreas Rossberg wrote: >> On 3 October 2012 05:38, Brendan Eich wrote: >>> Which is more important, iterating over holes (preserved if possible), or >>> skipping them and therefore spreading array-likes but not

RE: Sets plus JSON

(oops, forgot to reply-all) Begin forwarded message: > From: Allen Wirfs-Brock > Date: October 3, 2012 10:15:57 AM PDT > To: Herby Vojčík > Subject: Re: Sets plus JSON > > > On Oct 3, 2012, at 9:56 AM, Herby Vojčík wrote: > >> >> >> Nichol

Re: Symbols, Protocols, Frames, and Versioning

On Oct 3, 2012, at 2:09 PM, Brendan Eich wrote: > Domenic Denicola wrote: >> Would it suffice to allow cross-frame sharing of symbols via postMessage and >> its structured clone algorithm? They're immutable, right? > > They are immutable but you'd still have to pass your @iterator to another >

Re: Symbols, Protocols, Frames, and Versioning

presumably, looking up "iterator" in a registry of string/symbol key value pairs. Creating a new entry if one isn't present, and regardless returning the symbol value associated with the string. public @iterator = Symbol('iterator'); conceptually could just as easily be expressed as: public

Re: Symbols, Protocols, Frames, and Versioning

On Oct 4, 2012, at 10:09 AM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> presumably, looking up "iterator" in a registry of string/symbol key value >> pairs. Creating a new entry if one isn't present, and regardless returning >> the sym

Re: Sets plus JSON

On Oct 4, 2012, at 11:02 AM, Nicholas C. Zakas wrote: > > On 10/3/2012 4:44 PM, Allen Wirfs-Brock wrote: >> (oops, forgot to reply-all) >> >> Begin forwarded message: >> >>> From: Allen Wirfs-Brock >>> Date: October 3, 2012 10:15:57 AM PDT

Re: Symbols, Protocols, Frames, and Versioning

On Oct 4, 2012, at 11:29 AM, Brendan Eich wrote: > Tab Atkins Jr. wrote: >> It might be useful to expose this functionality with a more obvious >> name, to underscore that you lose the secrecy/unforgability. >> Symbol.public()? > > We are mooting public as the keyword for non-private but unique

Re: Symbols, Protocols, Frames, and Versioning

On Oct 4, 2012, at 11:50 AM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> ... > >> Note that in most cases, you want to look up an already interned symbol name >> rather than intern a new one. If the lookup falls back to creating, typos >> will tend

Re: Symbols, Protocols, Frames, and Versioning

Presumably, this concern would also apply to associating programmer supplied debug info with symbols "Mark S. Miller" wrote: >On Thu, Oct 4, 2012 at 11:41 AM, Allen Wirfs-Brock >wrote: > >Note that in most cases, you want to look up an already interned symbol name >

Re: Symbols, Protocols, Frames, and Versioning

mind? > >On Thu, Oct 4, 2012 at 1:18 PM, Allen Wirfs-Brock >wrote: > >Presumably, this concern would also apply to associating programmer supplied >debug info with symbols > > > > >"Mark S. Miller" wrote: > >On Thu, Oct 4, 2012 at 11:41 AM, Allen

Re: Symbols, Protocols, Frames, and Versioning

On Oct 4, 2012, at 4:02 PM, Brendan Eich wrote: > Dave had a suggestion for an alternative name to Symbol.intern, it's so > obvious in hindsight: > > public @iterator = Symbol.from('iterator'); > > No jargon, perhaps at the price of connoting singleton symbol, but still. Symbol.for('ite

Re: Sets plus JSON

On Oct 4, 2012, at 5:32 PM, Rick Waldron wrote: > > > On Thu, Oct 4, 2012 at 8:16 PM, Brendan Eich wrote: > Nicholas C. Zakas wrote: > I agree, I'm not sure there is a rational default for Map, but I think there > is one for Set as an array (and it seems like most people agreed). > > As with

Re: Sets plus JSON

On Oct 4, 2012, at 9:02 PM, Rick Waldron wrote: > > > On Thursday, October 4, 2012 at 9:29 PM, Allen Wirfs-Brock wrote: > >> >> On Oct 4, 2012, at 5:32 PM, Rick Waldron wrote: >> >>> >>> >>> On Thu, Oct 4, 2012 at 8:16 PM, Brendan

Re: Symbols, Protocols, Frames, and Versioning

On Oct 5, 2012, at 7:11 AM, Sam Tobin-Hochstadt wrote: > On Fri, Oct 5, 2012 at 8:45 AM, Andreas Rossberg wrote: >> Indeed, which is why I'm not sure I understand what this idea is >> trying to achieve. Is it more than just an ad hoc way to introduce a >> second namespace? > > I think what's go

issue: function hoisting and parameter default value initialization

The Sept 20 TC39 meeting notes says the following was (almost) agreed regarding function parameter scoping, pending some further investigation. > Temporarily, this happened: > Conclusion/Resolution > - `var` bindings and are in scope within the function > - cannot use `let` to shadow a paramete

Re: Symbols, Protocols, Frames, and Versioning

On Oct 6, 2012, at 4:47 AM, David Bruant wrote: > I think there is an idea which hasn't been mentionned yet which would be to > let programmers "merge" or "assimilate" cross-frame symbols. Basically, when > receiving a symbol from some frame, it'd be possible to say "I assimilate > this symbol

Re: Symbols, Protocols, Frames, and Versioning

On Oct 6, 2012, at 9:37 AM, Brendan Eich wrote: > Domenic Denicola wrote: >> I still would like to see someone respond to jjb’s message though: >> https://mail.mozilla.org/pipermail/es-discuss/2012-October/025531.html > > JJB is right about same-origin allowing sharing so making postMessage >

Re: Symbols, Protocols, Frames, and Versioning

On Oct 6, 2012, at 2:57 PM, Kevin Smith wrote: > > The issue, is providing access to an already created symbol across such > boundaries. As I have pointed out in other messages, this isn't a problem > that it unique to symbols. It is isomorphic with use cases for sharing any > kind of objec

<    4   5   6   7   8   9   10   11   12   13   >