Re: __doc__ for functions, classes, objects etc.

On 31.08.2011 18:38, Allen Wirfs-Brock wrote: On Aug 31, 2011, at 1:57 AM, Dmitry A. Soshnikov wrote: On 30.08.2011 20:39, Allen Wirfs-Brock wrote: On Aug 30, 2011, at 12:39 AM, Dmitry A. Soshnikov wrote: OK, let's up the topic. Seems there are no technical issues in the proposed

Re: __doc__ for functions, classes, objects etc.

On 30.08.2011 20:39, Allen Wirfs-Brock wrote: On Aug 30, 2011, at 12:39 AM, Dmitry A. Soshnikov wrote: OK, let's up the topic. Seems there are no technical issues in the proposed thing -- we can simply either accept it or not. The question is whether it's needed and sound propos

Re: __doc__ for functions, classes, objects etc.

Dave *From:*es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] *On Behalf Of *Dmitry A. Soshnikov *Sent:* Tuesday, August 30, 2011 7:42 AM *To:* Rick Waldron *Cc:* Brendan Eich; es-discuss Steen *Subject:* Re: __doc__ for functions, classes, objects etc. On 30.08.2011

Re: __doc__ for functions, classes, objects etc.

On 30.08.2011 19:54, Rick Waldron wrote: On Tue, Aug 30, 2011 at 10:41 AM, Dmitry A. Soshnikov mailto:dmitry.soshni...@gmail.com>> wrote: On 30.08.2011 17:41, Rick Waldron wrote: On Tue, Aug 30, 2011 at 3:39 AM, Dmitry A. Soshnikov mailto:dmitry.soshni...@gmail.com>&g

Re: __doc__ for functions, classes, objects etc.

On 30.08.2011 19:33, Dean Landolt wrote: On Tue, Aug 30, 2011 at 10:41 AM, Dmitry A. Soshnikov mailto:dmitry.soshni...@gmail.com>> wrote: On 30.08.2011 17:41, Rick Waldron wrote: On Tue, Aug 30, 2011 at 3:39 AM, Dmitry A. Soshnikov mailto:dmitry.soshni...@gmail.com>&g

Re: __doc__ for functions, classes, objects etc.

On 30.08.2011 17:41, Rick Waldron wrote: On Tue, Aug 30, 2011 at 3:39 AM, Dmitry A. Soshnikov mailto:dmitry.soshni...@gmail.com>> wrote: OK, let's up the topic. Seems there are no technical issues in the proposed thing -- we can simply either accept it or not. The

Re: An news on block lambda versus arrow function syntax?

On 30.08.2011 18:22, Axel Rauschmayer wrote: Is there a consensus building in TC39 for one or the other? Will any of them make it into ES.next? What I like about block lambdas is that one will automatically use lexical "this" where necessary. Just yesterday, dynamic "this" versus lexical "this

Re: __doc__ for functions, classes, objects etc.

ring 2.2. return String(doc) It's a simplified version of course (moreover, Allen wanted to eliminate [[Class]], so -- it's just an example). Do we need this? Dmitry. On 09.08.2011 23:59, Dmitry A. Soshnikov wrote: On 23.08.2011 20:54, Brendan Eich wrote: A convenient notation for

Re: Triple-strings

On 24.08.2011 20:19, Brendan Eich wrote: On Aug 24, 2011, at 2:44 AM, Dmitry A. Soshnikov wrote: Hi again, And another topic which I'd like to separate from the doc-comments topic is the "triple-strings". The rationale is not to escape the double/single quotes when descr

Triple-strings

Hi again, And another topic which I'd like to separate from the doc-comments topic is the "triple-strings". The rationale is not to escape the double/single quotes when describing something bigger than one line (usually these are comments, but other simple strings with many of double quotes a

Re: Object.methods

On 24.08.2011 3:07, Allen Wirfs-Brock wrote: On Aug 9, 2011, at 2:05 PM, Dmitry A. Soshnikov wrote: On 24.08.2011 0:39, Allen Wirfs-Brock wrote: I'm don't really see the that they are needed enough to build these in when they can be synthesized pretty easily. What is the justifi

Re: Object.methods

On 24.08.2011 0:39, Allen Wirfs-Brock wrote: On Aug 9, 2011, at 1:03 PM, Dmitry A. Soshnikov wrote: And what about this method Object.getMethods(...), Object.getMethodNames(...). Do we need it? I think it can be useful (since methods can be non-enumerable, and Object.keys(...) won't

Re: Object.methods

p, and after Object.getOwnPropertyNames(...) you have to manually filter them when `typeof` is "function") Dmitry. On Aug 7, 2011, at 12:36 PM, Dmitry A. Soshnikov wrote: Hi again, I'm about to propose `Object.methods(obj)` meta-method (or `Object.getMethods(obj)`).

Re: __doc__ for functions, classes, objects etc.

On 23.08.2011 20:54, Brendan Eich wrote: A convenient notation for multiline documentation comments, with convenient reflection (*not* via toString() scraping!), would be a fine thing. Yes, exactly this -- help(...) function, and also good auto-complete of object methods helped me some time

Re: __doc__ for functions, classes, objects etc.

So, is that's all? Anyone else thinks it's a needed thing in the ES? On 22.08.2011 14:57, Dmitry A. Soshnikov wrote: On 22.08.2011 12:47, Irakli Gozalishvili wrote: I'm very much interested in getting something like this! In fact I have been useing similar documentation styl

Re: __doc__ for functions, classes, objects etc.

e string escaping: function sum(a, b) { var doc = "Calculates \ sum of given\ `a` and `b` argumnets" return a + b } Yes, it's another pros to have [[Documentation]] standardized. On Sunday, 2011-08-07 at 21:30 , Dmitry A. Soshnikov wrote: On 21.08.2011 22:26, Peter v

Object.methods

Hi again, I'm about to propose `Object.methods(obj)` meta-method (or `Object.getMethods(obj)`). Unfortunately naming convention is inconsistent (arrgh!) -- `Object.keys` (hello, Ruby and Prototype.js) vs. Object.getOwnPropertyNames (o_O hello Java), so the method name can be chosen later. B

Re: __doc__ for functions, classes, objects etc.

On 21.08.2011 22:26, Peter van der Zee wrote: On Sun, Aug 7, 2011 at 6:56 PM, Dmitry A. Soshnikov wrote: Hi, What about to standardize (Python's) "__doc__"-umentation comments for JS? What's the difference between that and the /** ... */ way of "JSDoc"? /*

__doc__ for functions, classes, objects etc.

Hi, What about to standardize (Python's) "__doc__"-umentation comments for JS? Not exactly in this name with underscores, but the idea itself. I remember recent discussion on Twitter where Brendan proposed to use a prologue string for that: function foo() { "this is the super function" }

Re: Where in spec does it explain why setting the value of an existing property will change its [[Enumerable]] attribute.

It shouldn't, even in ES3 (read attentively). Dmitry. On 17.08.2011 8:44, John-David Dalton wrote: So @kitcambridge and I were talking spec and started trying to find in spec something that explains why something like: Array.prototype.reduce which is by default { [[Writable]]: true, [[Enumera

Re: Function#bind [[HasInstance]] question.

Once again (if the Twitter's discussion doesn't satisfy you): Quick overview: https://gist.github.com/1149186 Detailed overview: http://dmitrysoshnikov.com/notes/note-1-ecmascript-bound-functions/ So the Firefox is correct saying `true`. Dmitry. On 16.08.2011 18:26, John-David Dalton wrote:

Re: Shim for ES.next code?

There are many already I guess, e.g. pair of possible ES6 methods https://github.com/DmitrySoshnikov/es-laboratory/blob/master/src/es6.js, and also from any other framework (such as String.repeat). What's the goal? None of discussed methods is standardized yet. But, if you think currently need

Re: Term “data property” – ambiguous?

On 21.07.2011 19:10, Axel Rauschmayer wrote: Function-valued data properties = methods Non-function-valued data properties = ? Just properties. A "method" is just a `sounding sugar` for function-valued properties in this case. Dmitry. [[[Sent from a mobile device. Please forgive brevity a

Re: An "extend" operator is a natural companion to <|

On 19.07.2011 20:59, Brendan Eich wrote: On Jul 19, 2011, at 7:39 AM, Sean Eagan wrote: On Mon, Jul 18, 2011 at 4:01 PM, Brendan Eich wrote: // replace<| with<> let B = A<> {...}; // looks like a (prototype) chain link How so? I'm talking about visual similarity with an actual physical cha

Re: Summary: prototypes as classes

On 12.07.2011 0:18, Bob Nystrom wrote: I agree with Brendan's replies, but just to add some more color: On Sat, Jul 2, 2011 at 11:46 AM, Angus Croll > wrote: The concept itself is very simple - a dynamic archetype to be shared by all my instances: my protot

Re: Pure win: Array.from and Array.of

On 11.07.2011 20:01, Allen Wirfs-Brock wrote: On Jul 10, 2011, at 12:09 PM, Dmitry A. Soshnikov wrote: And by the way, an efficient `Array.prototype.unique` also would be nice to have, since in JS in general it's hard to implement it's efficiently (in lower level at least it wi

Re: Extending standard library of arrays

On 11.07.2011 16:49, David Bruant wrote: Le 11/07/2011 14:29, Dmitry A. Soshnikov a écrit : On 11.07.2011 2:42, David Bruant wrote: Le 10/07/2011 22:46, Dmitry A. Soshnikov a écrit : Here I put some extensions for arrays standard library (separated from this thread: https://mail.mozilla.org

Re: Extending standard library of arrays

On 11.07.2011 2:42, David Bruant wrote: Le 10/07/2011 22:46, Dmitry A. Soshnikov a écrit : Here I put some extensions for arrays standard library (separated from this thread: https://mail.mozilla.org/pipermail/es-discuss/2011-July/015856.html where Array.of and Array.from were considered

Re: Extending standard library of arrays

mitry. On 11.07.2011 0:46, Dmitry A. Soshnikov wrote: Here I put some extensions for arrays standard library (separated from this thread: https://mail.mozilla.org/pipermail/es-discuss/2011-July/015856.html where Array.of and Array.from were considered). We can consider also the following (as a

Extending standard library of arrays

Here I put some extensions for arrays standard library (separated from this thread: https://mail.mozilla.org/pipermail/es-discuss/2011-July/015856.html where Array.of and Array.from were considered). We can consider also the following (as a first step): *- Array.prototype.remove(value, all)*

Re: Pure win: Array.from and Array.of

On 11.07.2011 0:35, Brendan Eich wrote: On Jul 10, 2011, at 12:02 PM, Dmitry A. Soshnikov wrote: On 10.07.2011 22:44, Brendan Eich wrote: On Jul 10, 2011, at 10:40 AM, Dmitry A. Soshnikov wrote: On 10.07.2011 21:23, Brendan Eich wrote: On Jul 10, 2011, at 10:18 AM, Rick Waldron wrote: The

Re: Pure win: Array.from and Array.of

On 10.07.2011 23:25, Juan Ignacio Dopazo wrote: On Sun, Jul 10, 2011 at 2:35 PM, Dmitry A. Soshnikov mailto:dmitry.soshni...@gmail.com>> wrote: On 10.07.2011 21:32, Allen Wirfs-Brock wrote: On Jul 10, 2011, at 10:23 AM, Brendan Eich wrote: On Jul 10, 2011, at 10:18 AM

Re: Pure win: Array.from and Array.of

On 10.07.2011 23:09, Dmitry A. Soshnikov wrote: And by the way, an efficient `Array.prototype.unique` also would be nice to have, since in JS in general it's hard to implement it's efficiently (in lower level at least it will iterate faster). [1, 3, 2, 5, 5, 3].unique(); // [

Re: Pure win: Array.from and Array.of

And by the way, an efficient `Array.prototype.unique` also would be nice to have, since in JS in general it's hard to implement it's efficiently (in lower level at least it will iterate faster). [1, 3, 2, 5, 5, 3].unique(); // [1, 3, 2, 5] Dmitry. On 10.07.2011 23:02, Dmitry A.

Re: Pure win: Array.from and Array.of

On 10.07.2011 22:44, Brendan Eich wrote: On Jul 10, 2011, at 10:40 AM, Dmitry A. Soshnikov wrote: On 10.07.2011 21:23, Brendan Eich wrote: On Jul 10, 2011, at 10:18 AM, Rick Waldron wrote: The more I think about it, I still can't come up with any really exciting use cases where Arr

Re: Pure win: Array.from and Array.of

On 10.07.2011 22:26, John-David Dalton wrote: I dig Array.from, and have manually made sugar for that in my projects. Array.of is something I have also wanted though I had been struggling with a name for it. It's interesting -- can you show where and how? Until now if I wanted to avoid settin

Re: Pure win: Array.from and Array.of

And I don't see it still. Maybe you can explain it in some detail then if you have understood it? Dmitry. On 10.07.2011 21:33, Rick Waldron wrote: _that_ is the compelling use-case I was looking for. Rick -- Sent from my Palm Pre ---

Re: Pure win: Array.from and Array.of

On 10.07.2011 21:23, Brendan Eich wrote: On Jul 10, 2011, at 10:18 AM, Rick Waldron wrote: The more I think about it, I still can't come up with any really exciting use cases where Array.of would outshine anything that already exists. I say strike it from the wishlist. Hig

Re: Pure win: Array.from and Array.of

On 10.07.2011 21:32, Allen Wirfs-Brock wrote: On Jul 10, 2011, at 10:23 AM, Brendan Eich wrote: On Jul 10, 2011, at 10:18 AM, Rick Waldron wrote: The more I think about it, I still can't come up with any really exciting use cases where Array.of would outshine anything tha

Re: Pure win: Array.from and Array.of

On 10.07.2011 21:18, Brendan Eich wrote: On Jul 10, 2011, at 9:59 AM, Dmitry A. Soshnikov wrote: On 10.07.2011 20:36, Brendan Eich wrote: So the goal of Array.of is to provide a constructor that, unlike Array, does not have that insane special case for Array(42), which presets length (and

Re: Pure win: Array.from and Array.of

On 10.07.2011 20:36, Brendan Eich wrote: On Jul 10, 2011, at 3:06 AM, Dmitry A. Soshnikov wrote: Array.from is a good addition, I guess any good framework has it. Though, `Array.of` in contrast doesn't bring much of a sugar. Compare these two apples-to-apples: Array.of( "thin

Re: Array generation

On 10.07.2011 15:54, David Bruant wrote: Le 10/07/2011 12:06, Dmitry A. Soshnikov a écrit : (...) Another thing to consider is `Array.prototype.fill` method which we discussed before. The problem: Array(4).map(function(x) x * x); // [NaN, NaN, NaN, NaN] (by the way, this mistaken example is

Re: Pure win: Array.from and Array.of

On 10.07.2011 15:14, Mike Shaver wrote: On Sun, Jul 10, 2011 at 7:09 AM, Dmitry A. Soshnikov wrote: If I hadn't made map skip holes, then the fill pattern would be simple enough: Array(4).map(function (_,x) x * x); It's in particular case, you try to multiply indices, which

Re: Pure win: Array.from and Array.of

On 10.07.2011 14:27, Mike Shaver wrote: On Sun, Jul 10, 2011 at 6:06 AM, Dmitry A. Soshnikov wrote: The problem: Array(4).map(function(x) x * x); // [NaN, NaN, NaN, NaN] I think it actually produces just [ , , , , ], because map skips holes. (If you see the NaN behaviour in FF, please file

Re: Pure win: Array.from and Array.of

Array.from is a good addition, I guess any good framework has it. Though, `Array.of` in contrast doesn't bring much of a sugar. Compare these two apples-to-apples: Array.of( "things", "that", "aren't", "currently", "an", "array" ) vs. ["things", "that", "aren't", "currently", "an", "array"]

Re: Writing a desktop app in JavaScript?

Nevertheless, IMO this list is mostly for ES design. Practical JS application and tools better discuss in e.g. jsmentors list. Dmitry. On 03.07.2011 20:27, Axel Rauschmayer wrote: I hope the following question is not too out of place on this mailing list: JavaScript would really profit from a

Re: Making "super" work outside a literal?

On 26.06.2011 1:29, Axel Rauschmayer wrote: That would be enough. I guess I’m suggesting then to implement “super” like CoffeeScript does. Wouldn’t that be simpler? As my next message showed, Allen's http://wiki.ecmascript.org/doku.php?id=harmony:object_initialiser_super is like CoffeScript a

Re: Making "super" work outside a literal?

On 26.06.2011 1:06, Brendan Eich wrote: On Jun 25, 2011, at 2:01 PM, Dmitry A. Soshnikov wrote: On 26.06.2011 0:49, Brendan Eich wrote: On Jun 25, 2011, at 11:13 AM, Axel Rauschmayer wrote: I don’t know if this has been discussed, but I find the |super| work-around provided by YUI and

Re: Making "super" work outside a literal?

On 26.06.2011 0:49, Brendan Eich wrote: On Jun 25, 2011, at 11:13 AM, Axel Rauschmayer wrote: I don’t know if this has been discussed, but I find the |super| work-around provided by YUI and CoffeeScript (in the generated code) not that bad: ThisClass.__super__.foo.call(this, arg1, arg

Re: Is class syntax really necessary ?

On 13.06.2011 1:43, Dmitry A. Soshnikov wrote: On 13.06.2011 1:18, Brendan Eich wrote: On Jun 12, 2011, at 2:22 AM, Irakli Gozalishvili wrote: Hi, Is there anything else (other than starting this thread) I can do to make committee consider `Function.prototype.extend` as an alternative to a

Re: Is class syntax really necessary ?

On 13.06.2011 1:18, Brendan Eich wrote: On Jun 12, 2011, at 2:22 AM, Irakli Gozalishvili wrote: Hi, Is there anything else (other than starting this thread) I can do to make committee consider `Function.prototype.extend` as an alternative to a proposed class sugar ? Could you show Function

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

On 05.06.2011 22:00, Peter Michaux wrote: ES has "new Constructor()" as its basic syntax for construction. This means that if other constructors are also beneficial that the syntax to call them is inconsistent. For example, ES3 had the "String.fromCharCode" and ES5 added "Object.create". This i

Re: Array comprehensions shorter syntax (?)

On 01.06.2011 10:57, David Herman wrote: P.S.: another question I have -- is it worth and makes sense to raise a topic on considering/standardizing the pattern matching (Dave's proposal)? http://wiki.ecmascript.org/doku.php?id=strawman:pattern_matching Brendan mentioned on Twitter that it's "t

Re: Array comprehensions shorter syntax (?)

On 01.06.2011 3:06, Waldemar Horwat wrote: On 05/29/11 07:00, Dmitry A. Soshnikov wrote: Yeah, and ES also supports them. It's called a generator expression; in this proposal it would look like: let squares = (x * x | x < data, x > 5); Ahem, that's already a parenthesized

Re: Array comprehensions shorter syntax (?)

On 29.05.2011 23:29, Brendan Eich wrote: On May 29, 2011, at 7:17 AM, Jose Antonio Perez wrote: 2011/5/29 Dmitry A. Soshnikov <mailto:dmitry.soshni...@gmail.com>> That's it, exactly. We always looking for a shorter sugar. Though, the main thing that the sugar shouldn&#

Re: Array comprehensions shorter syntax (?)

:18 PM *To:* es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> *Subject:* Re: Array comprehensions shorter syntax (?) 2011/5/29 Dmitry A. Soshnikov <mailto:dmitry.soshni...@gmail.com>> Hi, Don't get this proposal as a bikesheding, just an idea in case if arrow fu

Re: Array comprehensions shorter syntax (?)

On 29.05.2011 16:18, Jose Antonio Perez wrote: 2011/5/29 Dmitry A. Soshnikov <mailto:dmitry.soshni...@gmail.com>> Hi, Don't get this proposal as a bikesheding, just an idea in case if arrow functions will win the block-functions. What about to make a s

Array comprehensions shorter syntax (?)

Hi, Don't get this proposal as a bikesheding, just an idea in case if arrow functions will win the block-functions. What about to make a sugar for Array comprehensions based also on arrow syntax? The same as in Erlang: let data = [1, 2, 3, 4, 5]; let squares = [x * x | x <- data, x > 3]; /

Re: Is class syntax really necessary ?

On 23.05.2011 14:17, Irakli Gozalishvili wrote: Hi, I think there lot's of proposals for ES.next that require syntax extensions, which is probably worth if new functionality added or shortens most commonly used constructs like functions (were no other option is available). In case of this pro

Re: paren-free call expressions

s: [1, 2, 3].map({|x| x * x}); right? (just asking to include to the following talk) Dmitry. On May 18, 2011, at 8:53 AM, Dmitry A. Soshnikov wrote: Hi, Parens-free call expression allow to provide some actions /decoratively/. From this, the consequence of easy and elegant DSLs (domain

paren-free call expressions

Hi, Parens-free call expression allow to provide some actions /decoratively/. From this, the consequence of easy and elegant DSLs (domain specific languages). For example: class Account { attributes "customer", "cart" } Thus, call to `attribute` function looks like not the imperative cal

Re: prototype for operator proposal for review

; of code reuse (in simple words -- just single inheritance), then the same keyword seems also logical. Dmitry. On 18.05.2011 11:41, Dmitry A. Soshnikov wrote: On 18.05.2011 6:50, Allen Wirfs-Brock wrote: We had so much fun with feedback on my Unicode proposal I just have open another one

Re: prototype for operator proposal for review

On 18.05.2011 6:50, Allen Wirfs-Brock wrote: We had so much fun with feedback on my Unicode proposal I just have open another one up for list feed back: An updated version of the "prototype for" (formerly proto) operator proposal is at http://wiki.ecmascript.org/doku.php?id=strawman:proto_ope

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

On 16.05.2011 19:02, Brendan Eich wrote: On May 16, 2011, at 4:54 AM, Dmitry A. Soshnikov wrote: On 16.05.2011 10:49, Brendan Eich wrote: On May 15, 2011, at 10:01 PM, Brendan Eich wrote: http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition#open_issues This

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

On 16.05.2011 10:49, Brendan Eich wrote: On May 15, 2011, at 10:01 PM, Brendan Eich wrote: http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition#open_issues This looks pretty good at a glance, but it's a /lot/, and it's new. Looking closer, I have to say something

Re: arrow syntax unnecessary and the idea that "function" is too long

On 16.05.2011 1:47, Brendan Eich wrote: On May 15, 2011, at 1:54 PM, Dmitry A. Soshnikov wrote: See last reply for more on joining. It occurs to me you thought scope chain varying in the context of a pure hash-rocket such as #->42 means that function cannot be joined, but since it is p

Re: arrow syntax unnecessary and the idea that "function" is too long

On 16.05.2011 0:40, Brendan Eich wrote: On May 15, 2011, at 11:56 AM, Dmitry A. Soshnikov wrote: Oh, and just a small note -- perhaps there's a sense to put a comment near each line to what result the expression evaluates in your examples, e.g. asset(p === q); // true (or false?) Th

Re: arrow syntax unnecessary and the idea that "function" is too long

On 16.05.2011 0:37, Brendan Eich wrote: On May 15, 2011, at 11:55 AM, Dmitry A. Soshnikov wrote: Oh, my misunderstanding then. Then I just incorrectly treated yours assert(p === q); This was from // Use # to freeze and join to nearest relevant closure function return_pure() { return #(a

Re: arrow syntax unnecessary and the idea that "function" is too long

Oh, and just a small note -- perhaps there's a sense to put a comment near each line to what result the expression evaluates in your examples, e.g. asset(p === q); // true (or false?) etc. Dmitry. On 15.05.2011 22:55, Dmitry A. Soshnikov wrote: On 15.05.2011 21:09, Brendan Eich wrote

Re: arrow syntax unnecessary and the idea that "function" is too long

On 15.05.2011 21:09, Brendan Eich wrote: On May 15, 2011, at 8:14 AM, Dmitry A. Soshnikov wrote: // Use # to freeze and join to nearest relevant closure function return_pure() { return #(a) -> a * a; } let p = return_pure () , q = return_pure () ; assert (p === q); So, ES3 joi

Re: arrow syntax unnecessary and the idea that "function" is too long

On 15.05.2011 10:33, Brendan Eich wrote: On May 13, 2011, at 11:25 PM, Brendan Eich wrote: I'll update http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax to include an ES5 grammar patch. Done: http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax, specifi

Re: Function Syntax

On 13.05.2011 1:25, Brendan Eich wrote: On May 12, 2011, at 1:06 PM, Brendan Eich wrote: On May 12, 2011, at 10:55 AM, Brendan Eich wrote: Ruby is far from simple, btw. Check out http://samdanielson.com/2007/3/19/proc-new-vs-lambda-in-ruby and the wikipedia page it references. Looks like P

Re: Best practices for exception handling?

On 30.04.2011 0:22, Axel Rauschmayer wrote: Would it make sense to standardize more exception/error types, for example to add a MissingParameterError in ES.next? No proposal yet for demanding actual parameter count match formal, so this would not be used. Right. I would use it when I do my ow

Re: Automatic Semicolon Insertion: value vs cost; predictability and control; alternatives

On 17.04.2011 21:07, Garrett Smith wrote: On 4/17/11, Brendan Eich wrote: On Apr 17, 2011, at 10:52 AM, Claus Reinke wrote: [TLDR] ASI is not going to be removed. I don't know why you think it could be. Why not? Iif developers would stop doing that then eventually, can't it be removed? It

Re: Existential operator

On 16.04.2011 2:28, David Herman wrote: The fact is that "dynamic scope" is used to mean multiple things: 1) the "stack-like" semantics employed by e.g. the original Lisps, and 2) any non-static scoping semantics. The former was so famous that it came to be the common usage of the term, but #1

Re: Existential operator

On 16.04.2011 1:17, Sam Tobin-Hochstadt wrote: On Fri, Apr 15, 2011 at 5:10 PM, Dmitry A. Soshnikov wrote: I don't know what else to say to persuade you of this, but making identifier resolution fast is not "the main reason". Oh, it's not required, I got it. And I als

Re: Existential operator

On 16.04.2011 0:45, Sam Tobin-Hochstadt wrote: On Fri, Apr 15, 2011 at 4:32 PM, Dmitry A. Soshnikov wrote: OK, what I was saying is that you mixing the terminology calling as "dynamic scope" the "runtime bindings". And I mentioned that the dynamic scope is when a bindin

Re: Existential operator

On 16.04.2011 0:59, Sam Tobin-Hochstadt wrote: On Fri, Apr 15, 2011 at 4:53 PM, Mark S. Miller wrote: I understand how dynamic scope works. And ES5 with the mutable global object has it: function bar() { return foo }; bar() // error: foo is not defined var foo = 7; bar(); // produces 7 Lexic

Re: Existential operator

On 16.04.2011 0:06, Brendan Eich wrote: On Apr 15, 2011, at 9:56 PM, Sam Tobin-Hochstadt wrote: 1. The global object (which is what's originally under discussion here) also gives you "dynamic scope" for top-level variables. Right -- this is important and it is a deoptimer for optimizing imple

Re: Existential operator

On 15.04.2011 23:56, Sam Tobin-Hochstadt wrote: On Fri, Apr 15, 2011 at 3:40 PM, Dmitry A. Soshnikov wrote: On 14.04.2011 23:40, Sam Tobin-Hochstadt wrote: On Thu, Apr 14, 2011 at 3:29 PM, Dmitry A. Soshnikov wrote: But these globals won't be accessible to scripts that have al

Re: Existential operator

On 14.04.2011 23:48, David Herman wrote: Dynamic binding is bad, mmmkay? ;) Mmmkay, Mr. Mackey :P But the main reason is increasing of performance. Of course, the understanding of _your bindings_ (i.e. which vars are present in the program) is also the reason, but it seems manageable. Serio

Re: Existential operator

On 14.04.2011 23:40, Sam Tobin-Hochstadt wrote: On Thu, Apr 14, 2011 at 3:29 PM, Dmitry A. Soshnikov wrote: But these globals won't be accessible to scripts that have already been compiled; only to scripts that are subsequently compiled and evaluated, e.g. via ModuleLoader.eval. Which

Re: Existential operator

On 14.04.2011 22:00, Brendan Eich wrote: On Apr 14, 2011, at 7:43 PM, Asen Bozhilov wrote: It will solve the problem with the ambiguous syntax. There is no ambiguity problem with ? followed by . and then (with whitespace allowed, of course) an IdentifierName. We need the lookahead to an ide

Re: Existential operator

On 14.04.2011 20:42, David Herman wrote: Think of it this way: dynamic binding no, dynamic assignment yes. Yes, I've already learned it testing modules. Though, should say that it will decrease the beauty JS definitions as runtime expressions. The price? -- interpreter efficiency of course

Re: Optional : in ?: operator [was: Existential operator]

On 14.04.2011 18:32, Dmitry A. Soshnikov wrote: On 14.04.2011 1:23, David Herman wrote: I don't think this feature is worth all this discussion or time, which is why I haven't said very much. But I don't like the idea. Are you talking about Kyles proposal or about my initial

Re: Optional : in ?: operator [was: Existential operator]

On 14.04.2011 1:23, David Herman wrote: I don't think this feature is worth all this discussion or time, which is why I haven't said very much. But I don't like the idea. Are you talking about Kyles proposal or about my initial? I remind, my initial proposal was exactly about "?." operator t

Re: Existential operator

On 13.04.2011 23:06, David Herman wrote: It'll be the WindowProxy as usual, in top level code. Dave has addressed what it will be in a module recently. I have to look on Dave's explanation, seems I missed it. But this WindowProxy won't be assessable then, right? Will it be possible to define a

Re: harmony:modules with require

On 14.04.2011 11:38, Irakli Gozalishvili wrote: Hi, I just noticed that harmony modules have a different spelling then it used to have: module YUI ='http://developer.yahoo.com/modules/yui3.js'; module YUI = require('http://developer.yahoo.com/modules/yui3.js'); I wanted to know what was a rea

Re: Existential operator

On 13.04.2011 22:25, Brendan Eich wrote: On Apr 13, 2011, at 8:01 PM, Dmitry A. Soshnikov wrote: (regardless that ES6 will have compile-time bindings, it still possible to create global var at runtime via `this.bar`, though, if there will be no global object, I'm not sure how this appli

Re: Existential operator

On 13.04.2011 21:57, Brendan Eich wrote: On Apr 13, 2011, at 3:38 PM, Kyle Simpson wrote: See http://wiki.ecmascript.org/doku.php?id=strawman:default_operator -- the proposal there is ?? and ??= since single ? is ambiguous after an expression due to conditional expressions (?:). The "defaul

Re: Existential operator

On 13.04.2011 17:38, Kyle Simpson wrote: See http://wiki.ecmascript.org/doku.php?id=strawman:default_operator -- the proposal there is ?? and ??= since single ? is ambiguous after an expression due to conditional expressions (?:). The "default operator" doesn't address a significant part of w

Re: Existential operator

On 13.04.2011 16:57, Brendan Eich wrote: See http://wiki.ecmascript.org/doku.php?id=strawman:default_operator -- the proposal there is ?? and ??= since single ? is ambiguous after an expression due to conditional expressions (?:). On Apr 13, 2011, at 11:37 AM, Dmitry A. Soshnikov wrote: let

Existential operator

Hi, (I separate it from recent thread on shared handlers for proxies). The existential operator is a syntactic sugar to avoid long testing whether a property exists and only after that to apply it. This already is again used in CoffeeScript, so I'll show the examples: let street = user.addre

Re: [Harmony proxies] Discussion on the "declarative object" experiment

On 13.04.2011 12:32, David Bruant wrote: Le 13/04/2011 10:18, Dmitry A. Soshnikov a écrit : On 13.04.2011 12:08, David Bruant wrote: Le 13/04/2011 09:02, Dmitry A. Soshnikov a écrit : Yes, the pattern is interesting, though, really, which practical use-case will it have? I warned from the

Re: [Harmony proxies] Discussion on the "declarative object" experiment

On 13.04.2011 12:08, David Bruant wrote: Le 13/04/2011 09:02, Dmitry A. Soshnikov a écrit : On 12.04.2011 20:41, David Bruant wrote: Hi, I'd like to share my experience on a recent experiment. First off, I'd like to apologize for the name; "declarative object" doesn'

Re: [Harmony proxies] Discussion on the "declarative object" experiment

On 12.04.2011 20:41, David Bruant wrote: Hi, I'd like to share my experience on a recent experiment. First off, I'd like to apologize for the name; "declarative object" doesn't really capture it and may be confusing. Second of all, what I have created doesn't really solve any use case (I'll d

Re: When is a JavaScript program "correct"? (was: Setting a property in the prototype chain?)

On 11.04.2011 22:37, Mark S. Miller wrote: On Sun, Apr 10, 2011 at 5:27 PM, Dmitry A. Soshnikov mailto:dmitry.soshni...@gmail.com>> wrote: As I see it, you address the "issue" of unstratified meta-programming (note, I take the "issue" in quotes, since t

Re: When is a JavaScript program "correct"? (was: Setting a property in the prototype chain?)

On 11.04.2011 18:07, Mark S. Miller wrote: On Sun, Apr 10, 2011 at 11:21 PM, David Herman > wrote: I wondered if someone was going to make this point. > That should be > > while (!{}.hasOwnProperty.call(obj, key)) > > which works even

Re: Setting a property in the prototype chain?

On 10.04.2011 21:24, Axel Rauschmayer wrote: As far as I am aware, there is no way to change a property that isn’t at the beginning of the property chain, because the change will create a new property there. Are there plans to change this? It would be nice to have something akin to class meth

Re: Questions about Harmony Modules

On 04.04.2011 18:40, David Herman wrote: Though the other question is: why do we need `require` at all? Purely for syntactic/practical reasons. Let's not bikeshed. Why I was asking -- because I saw it in your talk on ES.next, where you used exactly this approach, i.e. module Foo = "http:/

  1   2   3   >