Re: May 24-26 rough meeting notes

On May 29, 2011, at 12:55 PM, Thaddee Tyl wrote: > Don't be upset! Not at all, I'm simply skeptical (and saucy in saying so) about jurisdictional fights this early in thinking creatively about cross-cutting solutions. Seems kind of silly to call process police, doesn't it? > I just believe th

Re: May 24-26 rough meeting notes

On May 29, 2011, at 2:58 PM, Thaddee Tyl wrote: > ... I believe that, given the fact that browsers will implement > ES.next incrementally, we should find a way to allow graceful > fallback, rather than version-driven conditionals. This is trivial for new global object properties, but such additio

Re: May 24-26 rough meeting notes

On May 30, 2011, at 1:54 AM, Thaddee Tyl wrote: > On Mon, May 30, 2011 at 6:55 AM, Brendan Eich wrote: >> On May 29, 2011, at 2:58 PM, Thaddee Tyl wrote: >>> ... I believe that, given the fact that browsers will implement >>> ES.next incrementally, we should f

Re: real use of {const} and issues

On May 31, 2011, at 4:32 AM, Fyodorov Bga Alexander wrote: > my view of {const} keyword semantic > 1) alloced 1 time, as {var}, for correct work of closure > 2) assign w/o {const} redeclaration - (not silent) error > 3) assign w/ {const} redeclaration - change value That's what SpiderMonkey has d

Re: Proposal: Object.defineProperty shorthand

On May 31, 2011, at 11:52 AM, Sean Eagan wrote: > I still like the syntax proposed at the beginning of the thread the best. I like # for non-configurable, ! for non-writable, and ~ for non-enumerable too. All prefixes. But not for assignment expressions as I think you showed -- only in object i

Re: May 24-26 rough meeting notes

On May 31, 2011, at 1:21 PM, Waldemar Horwat wrote: > On 05/27/11 19:36, Brendan Eich wrote: >> On May 27, 2011, at 6:42 PM, Brendan Eich wrote: >> >>> On May 27, 2011, at 6:20 PM, Waldemar Horwat wrote: >>> >>>>> This produces expressi

Re: May 24-26 rough meeting notes

On May 31, 2011, at 2:30 PM, Waldemar Horwat wrote: > I would not want to use anything like a PEG to standardize a grammar. Here's > why: > > PEG being unambiguous by construction simply means that it resolves all > ambiguities by picking the earliest rule. This turns all rules following the

Re: May 24-26 rough meeting notes

On May 31, 2011, at 3:59 PM, Waldemar Horwat wrote: > I don't understand the premise of your comment on ASI. Here there *is* an > error in parsing without a virtual semicolon and no error in parsing with a > virtual semicolon, so a PEG-like ASI would erroneously insert one. Sorry, I misread t

Re: Proxies with State

On May 31, 2011, at 4:57 PM, Cormac Flanagan wrote: > One possible concern with proxies is the overhead of separate proxy > and handler objects, and trap methods that likely close over a backing > object. Or weakmap proxies to backing objects. > This concern would be exacerbated in the case of

Re: May 24-26 rough meeting notes

On May 31, 2011, at 9:08 PM, Kam Kasravi wrote: > On May 31, 2011, at 2:55 PM, Brendan Eich wrote: > >> On May 31, 2011, at 2:30 PM, Waldemar Horwat wrote: >> >>> I would not want to use anything like a PEG to standardize a grammar. >>> Here'

Re: May 24-26 rough meeting notes

On May 31, 2011, at 10:07 PM, Kam Kasravi wrote: > Is it a given that the grammar extensions in the various strawmen are all > LR(1)? See earlier in this thread, where this strawman was mentioned as requiring either a cover grammar for ArrowFormalParameters (namely Expression), plus a restric

Re: Proposal: Object.defineProperty shorthand

On May 31, 2011, at 2:25 PM, Allen Wirfs-Brock wrote: > This is as plausible as using ! for non-configurable as I had proposed. It > really comes down to alignment with other uses of #. It is pretty easy to > make a logical association between this mapping of symbols to meanings. > However,

Re: Array comprehensions shorter syntax (?)

On Jun 1, 2011, at 12:21 AM, Dmitry A. Soshnikov wrote: > Ah, come on, of course I didn't compare them apples-to-apples. Just said that > it's more likely that some elegant and powerful syntactic construction/sugar > will be used more often than use-cases with WeakMaps and it turns out that > m

Re: [Arrow function syntax] Move Arrow to head to fix ArrowFormalParameters issues

On Jun 1, 2011, at 8:30 AM, Sean Eagan wrote: > Why not just move Arrow to the head to avoid any current or future > ArrowFormalParameters parsing issues such as the GLR issue ? There's no GLR issue if we do what we're doing for assignment expressions, including destructuring: parse a cover gram

Re: [Arrow function syntax] Move Arrow to head to fixArrowFormalParameters issues

On Jun 1, 2011, at 9:17 AM, François REMY wrote: > It seems you're rethrowing the -> vs the @ syntax debate. (replace -> by @ in > your proposal, you'll get the initial proposal I did) @ is wanted for private names. There's no need to go a bikeshed- or snipe-hunt for coveted, scarce single ASC

Re: May 24-26 rough meeting notes

On Jun 1, 2011, at 10:07 AM, Jorge wrote: >>> A block: >>> { noLabelHere ... } >>> >> We didn't talk about this change. It is yet another migration early-error to >> consider. > > But it's not very usual to begin a block with a label. You're right, and it can be an ArrowBodyBlock, not a backwa

Re: [Arrow function syntax] Move Arrow to head to fixArrowFormalParameters issues

On Jun 1, 2011, at 10:38 AM, François REMY wrote: > Last time I asked, it was the "#" char that was wanted for private names. If > "#" has been replaced by "@" in private names, then we can replace "@" by "#" > in my proposal, and return to the original proposal of #functions. # is wanted for f

Re: [Arrow function syntax] Move Arrow to head to fixArrowFormalParameters issues

On Jun 1, 2011, at 11:53 AM, François REMY wrote: > Ok, then I'm fine with it. Please note that the current strawman still make > use of the # symbol, which is why I thought you were using both of them in a > future proposal. You must be reading an older strawman. The one promoted to Harmony la

Re: PTC and "SHOULD" vs "MUST"

Thanks for catching this, it goes back to http://wiki.ecmascript.org/doku.php?id=strawman:proper_tail_calls&rev=1273414092 (first rev). Cc'ing Mark. I bet it is just a thinko for MUST and we can fix it quickly. /be On Jun 1, 2011, at 3:36 PM, Peter Michaux wrote: > http://wiki.ecmascript.org/

Re: statements that could be expressions?

On Jun 1, 2011, at 5:16 PM, Mike Samuel wrote: > The semantics of all of these are specified in terms of expression > semantics. Every statement or expression is specified in terms of a > triple of (one of (normal, throw, break, continue), value, label). Alas, only statements have Completion res

Re: Regex on substrings

Note that http://wiki.ecmascript.org/doku.php?id=harmony:regexp_y_flag has been promoted to harmony:proposals status (see http://wiki.ecmascript.org/doku.php?id=harmony:proposals), so very likely to be in ES.next. With this flag on a regexp, you don't need extra arguments for a suite of metho

Re: how to create strawman proposals?

On Jun 2, 2011, at 4:16 PM, Kyle Simpson wrote: > Is it available for general public members to register for an account to > create strawman proposals for ES? No, it's an Ecma TC39 resource. Ecma needs IPR handoff per its patent covenant so this can't be a free-for-all, for better or worse. >

Re: how to create strawman proposals?

On Jun 2, 2011, at 5:56 PM, Kyle Simpson wrote: >>> Is it available for general public members to register for an account to >>> create strawman proposals for ES? >> >> No, it's an Ecma TC39 resource. Ecma needs IPR handoff per its patent >> covenant so this can't be a free-for-all, for better

Re: statements that could be expressions?

On Jun 1, 2011, at 5:52 PM, Waldemar Horwat wrote: > On 06/01/11 16:07, Peter Michaux wrote: >> Could some of JavaScript's statements also be allowed as expressions? >> >> In Perl there is the common idiom when opening a file >> >> open F, "< $f" or die "Can't open $f : $!"; >> >> In JavaScr

Re: statements that could be expressions?

On Jun 2, 2011, at 8:12 PM, Brendan Eich wrote: >> - Conflict between blocks and statements: >> >> a = {x: while (x) { ... break x;}} >> >> is either an object initializer or a block containing a labeled while >> statement. > &

Re: how to create strawman proposals?

On Jun 2, 2011, at 10:15 PM, Kyle Simpson wrote: >>> So if a non-TC39 member wants to create suggestions and proposals and ideas >>> for the community to discuss, am I to understand that not only this list, >>> but also the wiki that this list so frequently references, are not really >>> intend

Re: Default non-capturing regex flag [WAS: how to create strawman proposals?]

On Jun 2, 2011, at 10:46 PM, Kyle Simpson wrote: > I propose a /n flag for regular expressions, which would swap the default > capturing/non-capturing behavior between ( ) and (?: ) operators (that is, ( > ) would not capture, and (?: ) would capture). I like it. No worries about the .NET somew

Re: Default non-capturing regex flag [WAS: how to create strawman proposals?]

On Jun 2, 2011, at 10:49 PM, Brendan Eich wrote: > On Jun 2, 2011, at 10:46 PM, Kyle Simpson wrote: > >> I propose a /n flag for regular expressions, which would swap the default >> capturing/non-capturing behavior between ( ) and (?: ) operators (that is, ( >>

Re: statements that could be expressions?

On Jun 3, 2011, at 3:11 PM, Waldemar Horwat wrote: > On 06/02/11 20:12, Brendan Eich wrote: >>> - Conflict between blocks and statements: >>> >>> a = {x: while (x) { ... break x;}} >>> >>> is either an object initializer or a block contai

Re: statements that could be expressions?

On Jun 3, 2011, at 4:04 PM, Brendan Eich wrote: > On Jun 3, 2011, at 3:11 PM, Waldemar Horwat wrote: > >> Don't you also want to allow (either now or in the future) for the shorthand >> {x, y} to mean {x:x, y:y}? There are also getters, setters, and various >> oth

Re: block lambda revival

On Jun 4, 2011, at 6:32 AM, Peter Michaux wrote: > On Fri, May 20, 2011 at 5:54 PM, Brendan Eich wrote: >> As promised/threatened: >> http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival > > The examples on the wiki page feature calling a function t

Re: class sugar

On Jun 4, 2011, at 3:00 PM, Peter Michaux wrote: > On Sat, Jun 4, 2011 at 9:52 AM, Juan Ignacio Dopazo > wrote: >> Both styles are equally useful. Prototype based code has its own advantages >> such as being able to easily modify the behavior of multiple objects on the >> fly (very useful when wo

Re: Different semantics should have different-looking syntax

On Jun 4, 2011, at 7:24 PM, Peter Michaux wrote: > On Sat, May 21, 2011 at 12:37 PM, Brendan Eich wrote: >> For http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival I >> have written up the Ruby-inspired {|x| x * x} syntax. >> >> Alternatives (ignorin

Re: block lambda revival, now with semantics

On Jun 4, 2011, at 7:55 PM, Peter Michaux wrote: > Would we be able to do the following to ensure the file is closed if > "fn" is either a function that throws or is a lambda that returns? > >var withFile = function(filename, fn) { >var file = openFile(filename); >try { >

Re: The other constructors: Object.create() and String.fromCharCode()

On Jun 5, 2011, at 11:00 AM, Peter Michaux wrote: > (I remember the idea of being able to write "String.new" rather than > having to write "String['new']" was discussed in the past. I don't > know if keywords as bare object keys are allowed in ECMAScript but it > seems to work in Firefox.) It's i

Re: Default non-capturing regex flag [WAS: how to create strawman proposals?]

On Jun 3, 2011, at 10:49 AM, Juriy Zaytsev wrote: > Chrome (13) and Safari (5) tolerate "n". No error. Bugs filed? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Harmony classes

On Jun 5, 2011, at 10:59 PM, Kam Kasravi wrote: > From the harmony classes example copied below for reference. > The set health(value) {...} assigns a new value to this.health. But health is > a private property, so the assignment is setting a public property. Shouldn't > the assignment be priva

Re: Harmony object literals

On Jun 6, 2011, at 9:38 AM, Kam Kasravi wrote: > I see, the object's prototype is to the left of <| and the actual object is > to the right. I guess that was made clear in the proposal though I suspect > others will invert the relationship since javascript programmers are used to > defining the

Re: Default non-capturing regex flag [WAS: how to create strawman proposals?]

Escapes are a pain, due to the double-backslash burden. We really want quasis for this kind of extensibility. Quasis solve the multiline problem too (I hope... :-). /be On Jun 6, 2011, at 9:52 AM, Mike Samuel wrote: > 2011/6/3 Kyle Simpson : >> I propose a /n flag for regular expressions, whic

Re: class sugar: static inheritance

On Jun 6, 2011, at 10:19 AM, Bob Nystrom wrote: > On Sun, Jun 5, 2011 at 9:35 PM, Peter Michaux wrote: > Based on my understanding of what the desugared code would be, the > last line above would be an error because Dragon.allMonsters is > undefined. > > That's correct. Do you have any examples

Re: Feedback and criticism wanted: DOMCrypt API proposal

On Jun 6, 2011, at 9:51 AM, David Dahl wrote: > On 6/6/11 at 11:00,fra...@pwpconsult.com (Bill Frantz) wrote: >> On 6/1/11 at 16:01, dd...@mozilla.com (David Dahl) wrote: > >>> The property is namespaced in order to provide future capabilities. The >>> current design is asynchronous and looks li

Re: Thoughts on WeakMaps

On Jun 7, 2011, at 7:41 AM, David Bruant wrote: > Le 06/06/2011 17:31, David Bruant a écrit : >> myWeakMap.set(key, value) doesn't return anything. It could return the >> previous value for the key (if such a thing exists). Is it intentional that >> the set function doesn't return anything? > An

Re: I noted some open issues on "Classes with Trait Composition"

ly, and avoid preempting "new", we've settled on "constructor". The bigger issues with classes to close down include private instance variable syntax and semantics, and static method s&s. Some followup work is already under way here. We need to get this solid by the July

Re: Thoughts on WeakMaps

On Jun 7, 2011, at 1:59 PM, Mark S. Miller wrote: > Even from a security perspective, I don't think the leakier choice here is > fatal. But it does make it yet harder to avoid leakage accidents. How big a > deal this is depends on what you care about. I think you've made a good case for the des

Re: Harmony:classes static and private

On Jun 7, 2011, at 3:31 PM, Mark S. Miller wrote: > We have talked about adding some way to state class-private per-class > variable declarations without having to place them textually outside the > class. However, a problem with "static private" is that it suggests that such > things are prope

Re: Harmony:classes static and private

ables. But yes, we >> could do either. >> >> >> On Tue, Jun 7, 2011 at 4:07 PM, Brendan Eich wrote: >> On Jun 7, 2011, at 3:31 PM, Mark S. Miller wrote: >> >> > We have talked about adding some way to state class-private per-class >> > v

Re: class sugar: static inheritance

laceholder too. It doesn't help to think of it as a record. It probably does not help to think of it as an object, either, especially if you cannot get at it via anything like the still-straw private(this) or private(other) syntax. On another topic, it does seem like "protected" is

Re: class sugar: static inheritance

On Jun 8, 2011, at 3:41 AM, Kam Kasravi wrote: > I was wondering if this could be solved in some way without explicitly > referencing the particular Constructor. This isn't a static private issue per > se, rather a suggestion for an operator that would allow one to reference > Monster.allMonste

Re: class sugar: static inheritance

On Jun 8, 2011, at 8:14 AM, Mark S. Miller wrote: > The "private record" especially views as an "object" is a kind of placeholder > too. It doesn't help to think of it as a record. It probably does not help to > think of it as an object, either, especially if you cannot get at it via > anything

Re: class sugar: static inheritance

On Jun 8, 2011, at 8:50 AM, Mark S. Miller wrote: > On Wed, Jun 8, 2011 at 8:27 AM, Brendan Eich wrote: >> Btw, in both C++ and Java, the semantics of "protected" is a mess, in >> different ways. > > Sure. Let's not make those mistakes. Non-fixable in yo

Re: Harmony:classes static and private

On Jun 8, 2011, at 11:13 AM, Bob Nystrom wrote: > Either I'm out-of-date or the wiki page is. My understanding is that at the > TC39 meetings we decided to move instance and private record declarations out > of the class body and into the constructor. If that's the case, this should > be less c

Re: Harmony:classes static and private

Or that was what I intended in rewriting the earlier proposal. Thanks to Mark for fixing whatever was broken. /be On Jun 8, 2011, at 3:40 PM, Brendan Eich wrote: > On Jun 8, 2011, at 11:13 AM, Bob Nystrom wrote: > >> Either I'm out-of-date or the wiki page is. My understandi

Re: Harmony:classes static and private

On Jun 8, 2011, at 4:04 PM, Bob Nystrom wrote: > On Wed, Jun 8, 2011 at 3:40 PM, Brendan Eich wrote: > No, it does not outlaw private and even public for class body elements that > define (without static or whatever we use instead of static) prototype > properties. >

Re: ES parsing tools (Re: Short Functions)

nd I was doing so well with picking the right "from" email address) > > On Mon, May 30, 2011 at 5:55 AM, Brendan Eich wrote: >> The validation we'd need would be >> that both grammars produce sentences only and exactly in the same language. >> /be > >

Re: super, self, and sideways & durable vs. template

On Jun 12, 2011, at 1:00 PM, Peter Michaux wrote: > Something I try to do when designing constructors is to ensure the > constructed objects will be durable. That is, if some code modifies or > breaks parts of the constructed object's exposed interface, the other > parts of the exposed interface s

Re: Is class syntax really necessary ?

tend again, and say how it solves the super-construct and super-method-call problems? /be > > Thanks > -- > Irakli Gozalishvili > Web: http://www.jeditoolkit.com/ > Address: 29 Rue Saint-Georges, 75009 Paris, France > > On Tuesday, 2011-05-24 at 24:48 , Brendan Eich wr

Re: Classes: suggestions for improvement

On Jun 12, 2011, at 2:22 PM, Axel Rauschmayer wrote: > (1) The syntax for private properties still is a bit clumsy, and @ feels like > wasting a nice symbol, how about using private.foo instead of > private(this).foo? No, you need private(other).foo or shorter for things like class Point {

Re: Classes: suggestions for improvement

On Jun 12, 2011, at 2:38 PM, Brendan Eich wrote: >> (3) Is "static const" possible? > > Yes, see Oops, accidentally cut "the grammar". ClassPropertyDefinition : static ExportableDefinition ExportableDefinition : Declaration and D

Re: Classes: suggestions for improvement

On Jun 12, 2011, at 2:22 PM, Axel Rauschmayer wrote: > I really like the proposal: it is very lightweight syntactic sugar. For > example, it is not that radically different from Resig’s Simple Inheritance > (whose "look" I like). There is good in the proposal, don't get me wrong. I worked on it

Re: Is class syntax really necessary ?

> >> /be >> >>> >>> Thanks >>> -- >>> Irakli Gozalishvili >>> Web: http://www.jeditoolkit.com/ >>> Address: 29 Rue Saint-Georges, 75009 Paris, France >>> >>> On Tuesday, 2011-05-24 at 24:48 , Brendan Eich w

Re: Is class syntax really necessary ?

On Jun 12, 2011, at 3:18 PM, Irakli Gozalishvili wrote: > On Monday, 2011-06-13 at 24:03 , Brendan Eich wrote: > >> On Jun 12, 2011, at 2:52 PM, Irakli Gozalishvili wrote: >>> Here is gist I wrote before: >>> >>> https://gist.github.com/986487#file_implem

Re: Classes: suggestions for improvement

On Jun 12, 2011, at 2:38 PM, Brendan Eich wrote: > Something about classes in JS makes me sad, an emotional effect I can't > explain fully. In part I fear the "lint brush" aspect I mentioned in the > thread Irakli just followed up: class syntax will grow lots of hair

Re: Is class syntax really necessary ?

On Jun 12, 2011, at 3:38 PM, Irakli Gozalishvili wrote: > On Monday, June 13, 2011, Brendan Eich wrote: >> On Jun 12, 2011, at 3:18 PM, Irakli Gozalishvili wrote:On Monday, 2011-06-13 >> at 24:03 , Brendan Eich wrote: >> >>On Jun 12, 2011, at 2

Re: Classes: suggestions for improvement

On Jun 12, 2011, at 3:43 PM, Axel Rauschmayer wrote: >>> (1) The syntax for private properties still is a bit clumsy, and @ feels >>> like wasting a nice symbol, how about using private.foo instead of >>> private(this).foo? >> >> No, you need private(other).foo or shorter for things like >> >>

Re: Classes: suggestions for improvement

On Jun 12, 2011, at 3:49 PM, Axel Rauschmayer wrote: >>> and the "static" keyword for defining class properties are welcome >>> additions. >> >> Why "static" is the wrong word: there is nothing compile-time about the >> class properties. Classes are expressible (anonymous, even), as well as >>

Re: super, self, and sideways & durable vs. template

On Jun 12, 2011, at 4:29 PM, Peter Michaux wrote: >> Just to be clear to everyone following, you could use the closure pattern as >> Mark showed, for sure. > > Yes. It seems that the major objection to the closure system is > "efficiency". In the tradeoffs, some people weigh the extra memory > a

Re: Classes: suggestions for improvement

On Jun 12, 2011, at 4:54 PM, Juan Ignacio Dopazo wrote: > If I understand correctly the reason for needing private(this).x is because > the private names proposal allows having a private name with the same name as > a common property. Whether private in class uses private name objects or some o

Re: Classes: suggestions for improvement

On Jun 12, 2011, at 8:46 PM, Axel Rauschmayer wrote: > I’ve only got one use case for this, but “class methods” would also work > better if they could be attached to the prototype (and subject to > inheritance) instead of the constructor. We had a thread about this, because Ruby and CoffeeScrip

Re: Classes: suggestions for improvement

On Jun 13, 2011, at 8:41 AM, Juan Ignacio Dopazo wrote: > On Sun, Jun 12, 2011 at 10:17 PM, Brendan Eich wrote: > > I'm not sure classes should grow to have private class or prototype variables > in ES.next. Mark stripped things down to help get classes in. The one reason

Re: Classes: suggestions for improvement

On Jun 13, 2011, at 10:33 AM, Kam kasravi wrote: > On Jun 12, 2011, at 10:49 PM, Brendan Eich wrote: > >> On Jun 12, 2011, at 8:46 PM, Axel Rauschmayer wrote: >> >>> I’ve only got one use case for this, but “class methods” would also work >>> better if the

Re: super, self, and sideways & durable vs. template

On Jun 13, 2011, at 10:38 AM, Bob Nystrom wrote: > On Sun, Jun 12, 2011 at 2:17 PM, Brendan Eich wrote: > But to use the prototypal pattern, you would want something that has been > discussed a bit: class elements (class body elements) defining > once-per-class-evaluation functi

Re: Classes: suggestions for improvement

+1. Very nicely put. /be On Jun 13, 2011, at 11:51 AM, Bob Nystrom wrote: > On Sun, Jun 12, 2011 at 2:38 PM, Brendan Eich wrote: > Something about classes in JS makes me sad, an emotional effect I can't > explain fully. > > > > I'm one of the biggest fans of

Re: Classes: suggestions for improvement

On Jun 13, 2011, at 12:26 PM, Brendan Eich wrote: > +1. Very nicely put. > > /be One more thought: >> >> >> In part I think class is the wrong word, as cowboyd tweeted (see below). >> >> Agreed. "class" isn't ideal, but it's proba

Re: [Harmony classes] method lexical scope for InstancePropertyDefinitions, PrototypePropertyDefinitions?

On Jun 14, 2011, at 2:45 PM, Gavin Barraclough wrote: > For example, given the following class: > > class Box { >Box(x, y, z, density) { >public x = x; >public y = y; >public z = z; >private density = density; >} > >public volume() >{ >retu

Re: Classes: suggestions for improvement

On Jun 13, 2011, at 10:07 PM, Peter Michaux wrote: > On Mon, Jun 13, 2011 at 12:31 PM, Brendan Eich wrote: > >> The language to emulate is Smalltalk, though. > > +1 to that; however, the ES class proposal is not very similar to > Smalltalk classes. Others are far more q

Re: Classes: suggestions for improvement

On Jun 14, 2011, at 8:51 PM, Breton Slivka wrote: > Perhaps I am overlooking something obvious, but is there something > wrong with calling a constructor function `constructor`, rather than > class or proto or prototype? Yes, we've been over this in various places, probably need it recorded on th

Re: Prototypes as the new class declaration

On Jun 14, 2011, at 10:08 PM, Allen Wirfs-Brock wrote: > The correspondence is even closer if we slightly extend the new operator. > Using current new operator semantics and my alternative way of defining > SkinnedMeesh and then executing: > let aSM = new SkinnedMesh(aGeo, aMat); > we would g

Re: Prototypes as the new class declaration

On Jun 14, 2011, at 10:59 PM, Brendan Eich wrote: > Parallel class-side inheritance can be done, IINM: > > const SkinnedMesh = THREE.Mesh <| { > constructor: THREE.Mesh <| function(geometry, materials) { Er, that should be ... THREE.Mesh.constructor <| function(.

Re: es-discuss Digest, Vol 52, Issue 58

On Jun 14, 2011, at 11:25 PM, Axel Rauschmayer wrote: > Cool! That’s what I meant when I wrote the following: > >> From: Axel Rauschmayer >> Date: June 13, 2011 10:55:56 GMT+02:00 >> To: Allen Wirfs-Brock , es-discuss >> >> Subject: Re: Classes: suggestions for improvement >> >>> The correspo

Re: Prototypes as the new class declaration

On Jun 14, 2011, at 11:59 PM, Axel Rauschmayer wrote: > Wouldn’t you add a class method like this? > > const SkinnedMesh = THREE.Mesh <| { > cm: function() { > } > ... > }; > > Then it could be invoked as SkinnedMesh.cm() (which to me is what a class > method is: there is a class named Sk

Re: Quasi-literals for templating?

On Jun 15, 2011, at 2:43 AM, Axel Rauschmayer wrote: >>> Has that been considered as a use case (e.g. after a compilation/generation >>> step?). But it doesn’t seem like identifier names are accessible to quasi >>> handlers, which would make this difficult. >> >> If the consensus ends up being

Re: [Harmony Proxies] Proposal: Property fixing

On Jun 15, 2011, at 5:19 AM, David Bruant wrote: > Le 15/06/2011 13:34, Tom Van Cutsem a écrit : >> >> (As an aside: re. the emulation of arrays, having a configurable [[Class]] >> such that |Object.prototype.toString.call(arrayproxy)| can return "[object >> Array]" seems like a more important

Re: [Harmony Proxies] Proposal: Property fixing

On Jun 15, 2011, at 8:51 AM, Allen Wirfs-Brock wrote: > From a posting I made earlier in this thread: > >> Doesn't this new proposal still preclude using proxies to create an exact >> emulation of the built-in Array object type. The "length" property of >> arrays is specified to be non-configu

Re: Quasi-literals for templating?

On Jun 15, 2011, at 8:36 AM, Axel Rauschmayer wrote: >> The point is that the callSiteId captures all the >> literal/constant/loop-invariant parts of the quasi, both raw and cooked >> ("expandedLP"). The remaining quasi handler parameters are the necessarily >> variable, evaluated-at-runtime su

Re: [Harmony Proxies] Proposal: Property fixing

On Jun 15, 2011, at 1:38 PM, Tom Van Cutsem wrote: > Object.defineProperty(arrayProxy, "length", { value: newValue }); > > This will modify the fixed property, which is legal since it is writable. > It may not be very elegant, but at least it's doable. Great. When in doubt, use brute force. >

Re: [Harmony Proxies] Proposal: Property fixing

On Jun 15, 2011, at 3:53 PM, Mark S. Miller wrote: > On Wed, Jun 15, 2011 at 2:10 PM, David Bruant wrote: > Le 15/06/2011 23:01, Tom Van Cutsem a écrit : > > Just realized: even though an arrayProxy could update its fixed > > "length" property, it would not be able to intercept updates "from the

Re: [Harmony Proxies] Proposal: Property fixing

On Jun 15, 2011, at 4:25 PM, Mark S. Miller wrote: > ES5 code can. Isn't that enough of an objection? People are filing bugs over > such observable (with ES5's meta-object API) differences among engines, > especially in the DOM where this is driving the WebIDL spec. > > Objection to what? This

Re: [Harmony classes] method lexical scope for InstancePropertyDefinitions, PrototypePropertyDefinitions?

On Jun 15, 2011, at 7:16 PM, Gavin Barraclough wrote: > On Jun 14, 2011, at 3:27 PM, Brendan Eich wrote: >> On Jun 14, 2011, at 2:45 PM, Gavin Barraclough wrote: >> >>> return x * y * z; >> >> This works for the public instance properties, but IIRC some

Re: Quasi-literals for templating?

My two cents: Ruby (with #{...} in its interpolated quasi-literal strings) and other languages allow pretty arbitrary expressions. The lexical issues are not insuperable. We are not really playing it "safe" by making narrow restrictions (such as Identifier expression only, or dotted identifier m

Re: Quasi-literals for templating?

On Jun 15, 2011, at 9:51 PM, Brendan Eich wrote: > My two cents: Ruby (with #{...} in its interpolated quasi-literal strings) > and other languages allow pretty arbitrary expressions. The lexical issues > are not insuperable. We are not really playing it "safe" by making nar

Re: Quasi-literals for templating?

On Jun 15, 2011, at 10:25 PM, Mike Samuel wrote: > 2011/6/15 Brendan Eich : >> On Jun 15, 2011, at 9:51 PM, Brendan Eich wrote: >> >> My two cents: Ruby (with #{...} in its interpolated quasi-literal strings) >> and other languages allow pretty arbitrary expressions

Re: [Harmony Proxies] Proposal: Property fixing

On Jun 16, 2011, at 9:09 AM, David Bruant wrote: > Le 16/06/2011 17:46, Mark S. Miller a écrit : >> >> On Thu, Jun 16, 2011 at 8:29 AM, David Bruant wrote: >> >> The question raised by Mark is: "should objects with noticeable custom >> internal method (array, host objects, proxies...) be allow

Re: [Harmony Proxies] Proposal: Property fixing

On Jun 16, 2011, at 9:18 AM, Mark S. Miller wrote: > On Thu, Jun 16, 2011 at 9:15 AM, Brendan Eich wrote: > We should have no more attribute "keywords" in property descriptors than we > need to model the semantics we wish to reflect on via Object.* APIs and > intercede

Re: [Harmony Proxies] Proposal: Property fixing

On Jun 16, 2011, at 11:26 AM, Mark S. Miller wrote: > On Thu, Jun 16, 2011 at 10:13 AM, David Bruant wrote: > Le 16/06/2011 18:15, Mark S. Miller a écrit : > > In summary, "configurable" was never a guarantee of anything. > > "non-configurable" was the only state that came with guarantees. Let's

Re: [Harmony Proxies] Proposal: Property fixing

On Jun 16, 2011, at 4:14 PM, Mark S. Miller wrote: > On Thu, Jun 16, 2011 at 4:05 PM, Brendan Eich wrote: > There is a second reason, mentioned recently: we are implementing the DOM on > top of proxies, and the current WebIDL spec has non-configurable properties > induced in its

Re: [Harmony Proxies] Proposal: Property fixing

On Jun 16, 2011, at 4:27 PM, Mark S. Miller wrote: > On Thu, Jun 16, 2011 at 4:23 PM, Brendan Eich wrote: > On Jun 16, 2011, at 4:14 PM, Mark S. Miller wrote: > >> On Thu, Jun 16, 2011 at 4:05 PM, Brendan Eich wrote: >> There is a second reason, mentioned recently: we are

Re: [Harmony Proxies] Proposal: Property fixing

On Jun 16, 2011, at 4:32 PM, Mark S. Miller wrote: > My "Bonus" remark was *only* about Array length. For a great number of > non-configurable properties (e.g. global vars in ES5 implementations, not > created by eval), we JIT authors need a general attribute to consult. We > aren't hardcoding,

Re: [Harmony Proxies] Proposal: Property fixing

On Jun 16, 2011, at 7:44 PM, Mark S. Miller wrote: > Although > still appears in "strawman", I believe we accepted its functionality (with > concrete syntax still TBD) into ES-next "proposal" status, so it will become > standard a

Re: [Harmony Proxies] Proposal: Property fixing

On Jun 16, 2011, at 8:58 PM, Cameron McCormack wrote: > Mark S. Miller: >> Although >> >> still appears in "strawman", I believe we accepted its functionality >> (with concrete syntax still TBD) into ES-next "proposal" status, so >>

Re: [Harmony Proxies] Proposal: Property fixing

On Jun 16, 2011, at 10:12 PM, Mark S. Miller wrote: > On Thu, Jun 16, 2011 at 9:29 PM, Cameron McCormack wrote: > Brendan Eich: > > Read-only and fixed length array subclassing should not require using > > a proxy to implement the subclass. > > I forgot a requirement:

<    2   3   4   5   6   7   8   9   10   11   >