Re: Alternative syntax for <|

On 11/16/11 11:45 AM, Erik Arvidsson wrote: Sorry for being too brief. Today the following works. f(); ... function f() { ... } but the following does not: f(); ... let f = function f() {}; I think it is important that we keep the forward reference behavior with classes. This requires a decla

Re: with

On 11/16/11 11:30 PM, David Herman wrote: <| On Nov 16, 2011, at 11:27 PM, Mark S. Miller wrote: On Wed, Nov 16, 2011 at 11:24 PM, David Herman > wrote: Someone who shall remain nameless shot this down when I floated it privately. But I just have to thro

Re: The class operator: a bridge between object and function exemplers

On 11/14/11 5:17 PM, Allen Wirfs-Brock wrote: On Nov 14, 2011, at 4:50 PM, David Flanagan wrote: On 11/14/11 4:16 PM, Allen Wirfs-Brock wrote: On Nov 14, 2011, at 3:15 PM, David Flanagan wrote: I have a bad feeling about making 'new' work with both functions and object exemplars.

Re: The class operator: a bridge between object and function exemplers

On 11/14/11 3:01 PM, Allen Wirfs-Brock wrote: On Nov 14, 2011, at 2:01 PM, Brendan Eich wrote: On Nov 14, 2011, at 12:16 PM, Allen Wirfs-Brock wrote: let Point = { x:0, y,0, constructor(x,y} { this.x=x; this.y=y; } }.constructor; //<--- note ad

Re: The class operator: a bridge between object and function exemplers

On 11/14/11 4:16 PM, Allen Wirfs-Brock wrote: On Nov 14, 2011, at 3:15 PM, David Flanagan wrote: I have a bad feeling about making 'new' work with both functions and object exemplars. If we can have two different types of classes, we're going to end up using typeof on our c

Re: The class operator: a bridge between object and function exemplers

On 11/14/11 3:01 PM, Allen Wirfs-Brock wrote: On Nov 14, 2011, at 2:01 PM, Brendan Eich wrote: On Nov 14, 2011, at 12:16 PM, Allen Wirfs-Brock wrote: let Point = { x:0, y,0, constructor(x,y} { this.x=x; this.y=y; } }.constructor; //<--- note ad

Re: Minimalist Classes

On 11/2/11 11:16 AM, Brendan Eich wrote: On Nov 2, 2011, at 10:52 AM, David Flanagan wrote: Could they have initializers that were automatically included in the constructor? I answered that in a gist comment. Yes, I like the CoffeeScript constructor(@x, @y){} shorthand. Dart picked up on

Re: Minimalist Classes

On 11/1/11 11:53 PM, Brendan Eich wrote: On Nov 1, 2011, at 10:27 PM, David Flanagan wrote: 1) Class bodies are new syntax, so you can introduce new keywords, right? So 'prop' or 'proto'? 'static' puts a property on the class. 'private' puts a (priva

Fwd: Re: Minimalist Classes

[Oops. Replied to Brendan personally rather than reply-all to the list.] Original Message Subject:Re: Minimalist Classes Date: Tue, 01 Nov 2011 22:15:42 -0700 From: David Flanagan To: Brendan Eich On 11/1/11 5:18 PM, Brendan Eich wrote: Love it or hate

Re: More thoughts on Allen’s class definition pattern

I've been noodling around with various syntax ideas in this post, and it has gotten pretty long, so here are the highlights: var obj = base <| {a:1,b:2}; // I think its okay as-is. var obj = {:base> a:1, b:2}; // Its not really an operator, anyway var obj = base prototype {a:1,b:

Re: [Harmony Proxies] Non-extensible, sealed and frozen Proxies

lly Java and XML stuff, and it has been dropped from the DOM Core spec. I don't think that anyone has a goal to allow a proxy-based implementation of Element, for example, to be inserted into a native Document. My understanding is that that is never going to work. So the Proxy spec does not need to work to enable that. David Flanagan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: May the defineProperty method of a proxy handler throw a TypeError?

On 6/20/11 1:13 AM, Tom Van Cutsem wrote [https://mail.mozilla.org/pipermail/es-discuss/2011-June/015352.html]: But my question remains: how important is it for a Proxy to be able to faithfully emulate the reject behavior of assignment in non-strict code? If it is important then we should probab

Re: Wanted: standard Array function to append an array's elements to another array

On 7/25/11 12:54 PM, Jeff Walden wrote: Object.defineProperty(Array.prototype, "pushAll", { enumerable: false, configurable: true, writable: true, value: function pushAll(other) { "use strict"; var t = ToObject(this); var length = ToUint32(t.length); var ot

Re: May the defineProperty method of a proxy handler throw a TypeError?

On 6/17/11 3:05 PM, David Bruant wrote: What about adding a "throw" argument to the defineProperty trap (and any trap for which the equivalent internal method has a "throw" argument) ? The engine would set the boolean value correctly depending on strict mode or any relevant parameter. Trap writer

Re: May the defineProperty method of a proxy handler throw a TypeError?

Option #2 is in line with how the current default 'set' behavior is specified at <http://wiki.ecmascript.org/doku.php?id=harmony:proxies#trap_defaults>. Cheers, Tom 2011/5/25 David Flanagan <mailto:dflana...@mozilla.com>> I'm using a proxy to implement

Re: Proxy forwarding handlers and accessor properties

On 6/16/11 5:20 PM, David Bruant wrote: Le 17/06/2011 01:54, David Flanagan a écrit : // When we create a proxy with a forwarding handler, though, the this value // is different in the two cases. var handler = { target: o, get: function(receiver, name) { return this.target

Proxy forwarding handlers and accessor properties

eiver The code that demonstrates this is below. It runs in the current Firefox Aurora. I have actually been affected by this issue when the proxy object is stored in a WeakMap but the object it is forwarding to is not in the WeakMap. David Flanagan if (this.console) print = console.log

Re: May the defineProperty method of a proxy handler throw a TypeError?

On 5/26/11 10:46 AM, David Bruant wrote: Le 26/05/2011 18:44, David Flanagan a écrit : I'd put that distinction in an abstract Proxy.Handler class and then rename the current Proxy.Handler to Proxy.ForwardingHandler. What do you call a "class" is is a constructor with some argum

Re: Proposal: Object.defineProperty shorthand

Is a not-quite-so-cryptic shorthand possible? Could you use #readonly, #hidden, and #fixed instead of !, ~ and #, for example? This would be more extensible. Maybe #sealed and #frozen for object, literals? David On 5/26/11 11:37 AM, Sean Eagan wrote: Note: This proposal stems from the

Re: May the defineProperty method of a proxy handler throw a TypeError?

On 5/26/11 9:35 AM, David Flanagan wrote: On 5/26/11 6:36 AM, Tom Van Cutsem wrote: Hi David, The short answer: if you also define a 'set' trap, throwing a TypeError from defineProperty() to signal rejection is appropriate Thanks. I was worried that defineProperty() was require

Re: May the defineProperty method of a proxy handler throw a TypeError?

ct silently. Option #1 would most closely follow the current ES5 spec, but would disallow the default 'set' trap behavior from being written in Javascript itself, since it's impossible to specify the value of the 'Throw' parameter in Javascript. Option #2 is in line with ho

Re: May the defineProperty method of a proxy handler throw a TypeError?

but would disallow the default 'set' trap behavior from being written in Javascript itself, since it's impossible to specify the value of the 'Throw' parameter in Javascript. Option #2 is in line with how the current default 'set' behavior is specified at &l

May the defineProperty method of a proxy handler throw a TypeError?

I'm using a proxy to implement the DOM NodeList interface. A NodeList object is array-like and has read-only, non-configurable array index properties. In my handler's set() and delete() methods, I just return false if an attempt is made to set or delete an indexed property. The defineProper

Re: New private names proposal

More musings: the current proposal allows this form where the generation of the private name is explicit: private x = new Name(); What if the silently generative form were not allowed? That would make the mapping of identifiers more explicit. And if so, could we replace = with a tok

Re: New private names proposal

On 12/22/2010 09:57 AM, Allen Wirfs-Brock wrote: I think there are some interesting ideas to explore in both D. Flanagan's proposal and D. Herman's variations upon it. However, they both seem to be ignoring the second primary use case that I identified: conflict-free extensions of build-in or thi

Re: New private names proposal

On 12/22/2010 01:02 AM, David Herman wrote: In order for this to work you have to abandon the idea of scoped private identifiers. I say: make all private identifiers scoped to the compilation unit. This is the part of your suggestion that I don't like: it makes private identifiers too blunt

Re: New private names proposal

On 12/21/2010 11:58 PM, Brendan Eich wrote: I'm not keen on adding # as a sigil for private names, but this is mostly because such things are ugly, Perlish line noise. Under the "explicit is better than implicit" philosophy, and in particular the desire to eliminate even a static (compile-tim

Re: New private names proposal

Brendan wrote: > use private cachedHotness; We have that kind of syntax reserved for pragmas: I know, and that is why I threw it out there. To me, this kind of messing around with the meaning of identifiers feels like a compile-time thing, not a runtime thing... Allen's proposal treats "

Re: New private names proposal

On 12/21/2010 04:25 PM, Brendan Eich wrote: Why does your expectation differ here compared to the following: MyAwesomeThing.prototype.myCoolFunction = function() { var cachedHotness = gensym(); if (!this[cachedHotness]) this[cachedHotness] = doExpensiveThing(this) return this[cachedHotness]; }

Re: [[Class]] Property of Host Object

Allen, The host vs. native distinction has long bothered me as well. Thanks for a particularly lucid explanation. In the next edition of the spec, perhaps you could go further and eliminate the use of the word "host" altogether, leaving you with only native objects and non-native objects.

Re: We need to name "EphemeronTable" (was: Do we need an experimental extension naming convention?)

Mark S. Miller wrote: However, many objected to "ephemeron" as obscure jargon. We have not yet settled the name we are giving this abstraction. It is the language of GC implementors, and won't make sense to JS programmers. I'll be happy with almost any name that everyone else can agr

Re: The precise meaning of "For each named own enumerable property name P of O"

Allen Wirfs-Brock wrote: ES5 section 12.6 (for-in statement) says: The mechanics and order of enumerating the properties (step 6.a in the first algorithm, step 7.a in the second) is not specified. Properties of the object being enumerated may be deleted during enumeration. If a property that h

Re: arguments.callee in Harmony

Brendan Eich wrote: SC.HAS_STRICT = (function() { "use strict"; return !(function() { return this; }()); }()); (Or something like that. I sure will be happy when there's an implementation to test this stuff against.) You don't need two levels of functions. I just spaced out on the "use

Re: arguments.callee in Harmony

return !(function() { return this; }()); }()); (Or something like that. I sure will be happy when there's an implementation to test this stuff against.) Otherwise, what you're testing for is something like "is this code currently running in strict mode"

Re: Comments on April draft specification

Here's another comment: the email address es5-feedb...@ecma-international.org that appears on the cover of the "final draft" specification for ES5 is inoperative. I misspelled it on my first attempt to send comments there, but a second attempt, with misspelling corrected, also bounced.

Comments on April draft specification

substantive comments and corrections on the new stuff (especially section 10). I'll try to review the rest of the spec as time allows, but I wanted to get this first batch of comments sent off today. David Flanagan 4.2, 2nd paragraph: says that properties hold methods, then defi

Re: ECMAScript 5th Edition Candidate Specification released by Ecma

Should I send comments on this "final draft" to this mailing list or to es5-feeb...@ecma-international.org (or to both)? David Flanagan Allen Wirfs-Brock wrote: As of today, the Candidate Specification approved at the March TC-39 meeting is publically available from the Ec

Re: Strict undefined this

e that makes intuitive sense, and the one that is easy to explain (say, if one were writing a book about this language). If safety and theoretical concerns don't dictate a choice, I'd argue that common sense suggests c. David Flanagan ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss