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
thing
On 30.08.2011 19:33, Dean Landolt wrote:
On Tue, Aug 30, 2011 at 10:41 AM, Dmitry A. Soshnikov
dmitry.soshni...@gmail.com 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
dmitry.soshni
On 30.08.2011 19:54, Rick Waldron wrote:
On Tue, Aug 30, 2011 at 10:41 AM, Dmitry A. Soshnikov
dmitry.soshni...@gmail.com 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
dmitry.soshni
...@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 17:41, Rick Waldron wrote:
On Tue, Aug 30, 2011 at 3:39 AM, Dmitry A. Soshnikov
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 proposal
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 multiline documentation comments, with
convenient
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 bit
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 justification
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
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
describing something bigger
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 style for some time
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
(...) 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)`). Unfortunately naming convention is inconsistent
(arrgh
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
help
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 van der Zee wrote:
On Sun, Aug 7, 2011 at 6:56 PM, Dmitry A. Soshnikov
dmitry.soshni
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
}
On 21.08.2011 22:26, Peter van der Zee wrote:
On Sun, Aug 7, 2011 at 6:56 PM, Dmitry A. Soshnikov
dmitry.soshni...@gmail.com wrote:
Hi,
What about to standardize (Python's) __doc__-umentation comments for JS?
What's the difference between that and the /** ... */ way of JSDoc
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.
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,
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:
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
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
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 Eichbren...@mozilla.com wrote:
// replace| with
let B = A {...}; // looks like a (prototype) chain link
How so?
I'm talking about visual similarity with an
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
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
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 will iterate
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 anguscr...@gmail.com
mailto:anguscr...@gmail.com wrote:
The concept itself is very simple - a dynamic archetype to be
shared by all my
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]
what's the goal in
On 10.07.2011 14:27, Mike Shaver wrote:
On Sun, Jul 10, 2011 at 6:06 AM, Dmitry A. Soshnikov
dmitry.soshni...@gmail.com 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
On 10.07.2011 15:14, Mike Shaver wrote:
On Sun, Jul 10, 2011 at 7:09 AM, Dmitry A. Soshnikov
dmitry.soshni...@gmail.com 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
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
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( things, that, aren't
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
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 http://Array.of/ would outshine
anything that
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
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
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 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. Soshnikov
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(); // [1, 3, 2, 5
On 10.07.2011 23:25, Juan Ignacio Dopazo wrote:
On Sun, Jul 10, 2011 at 2:35 PM, Dmitry A. Soshnikov
dmitry.soshni...@gmail.com 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
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
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)*
.
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 first step
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
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
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
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 is a
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 comma expression
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
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]; //
On 29.05.2011 16:18, Jose Antonio Perez wrote:
2011/5/29 Dmitry A. Soshnikov dmitry.soshni...@gmail.com
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
shorter syntax (?)
2011/5/29 Dmitry A. Soshnikov dmitry.soshni...@gmail.com
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 sugar for Array comprehensions based
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 dmitry.soshni...@gmail.com
mailto:dmitry.soshni...@gmail.com
That's it, exactly. We always looking for a shorter sugar.
Though, the main thing that the sugar
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
(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 up for list feed back
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 call,
.
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 specific languages). For example:
class Account {
attributes customer, cart
}
Thus, call
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
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
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,
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 joined
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
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
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
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
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
On 17.04.2011 21:07, Garrett Smith wrote:
On 4/17/11, Brendan Eichbren...@mozilla.com 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
On 14.04.2011 23:40, Sam Tobin-Hochstadt wrote:
On Thu, Apr 14, 2011 at 3:29 PM, Dmitry A. Soshnikov
dmitry.soshni...@gmail.com 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
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.
On 15.04.2011 23:56, Sam Tobin-Hochstadt wrote:
On Fri, Apr 15, 2011 at 3:40 PM, Dmitry A. Soshnikov
dmitry.soshni...@gmail.com wrote:
On 14.04.2011 23:40, Sam Tobin-Hochstadt wrote:
On Thu, Apr 14, 2011 at 3:29 PM, Dmitry A. Soshnikov
dmitry.soshni...@gmail.comwrote:
But these globals
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
On 16.04.2011 0:59, Sam Tobin-Hochstadt wrote:
On Fri, Apr 15, 2011 at 4:53 PM, Mark S. Millererig...@google.com 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();
On 16.04.2011 0:45, Sam Tobin-Hochstadt wrote:
On Fri, Apr 15, 2011 at 4:32 PM, Dmitry A. Soshnikov
dmitry.soshni...@gmail.com 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 binding
On 16.04.2011 1:17, Sam Tobin-Hochstadt wrote:
On Fri, Apr 15, 2011 at 5:10 PM, Dmitry A. Soshnikov
dmitry.soshni...@gmail.com 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
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
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
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 to
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?
I remind, my
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
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
array is to be defined in the
constructTrap function. The pattern is here.
Yes, the pattern is interesting, though, really, which practical
use-case will it have? Currently a one possible I see -- a query to
database with building the query itself. Sort of:
where
.name(Dmitry
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't
really capture
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 =
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
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
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
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 applies
On 11.04.2011 18:07, Mark S. Miller wrote:
On Sun, Apr 10, 2011 at 11:21 PM, David Herman dher...@mozilla.com
mailto:dher...@mozilla.com wrote:
I wondered if someone was going to make this point.
That should be
while (!{}.hasOwnProperty.call(obj, key))
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
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 =
On 03.04.2011 3:33, David Herman wrote:
Hi James,
1) Files as modules do not need module wrapper
Just to confirm, if a JS file contains only a module definition, the
module X{} wrapper is not needed?
That's correct.
2) Set module export value
Is it
On 30.03.2011 1:24, Allen Wirfs-Brock wrote:
On Mar 29, 2011, at 12:14 AM, Dmitry A. Soshnikov wrote:
On 29.03.2011 2:51, Allen Wirfs-Brock wrote:
...
Regarding classes in general I have the following table of classes
kinds:
|first-class | second-class
On 29.03.2011 2:51, Allen Wirfs-Brock wrote:
On Mar 28, 2011, at 1:53 PM, Dmitry A. Soshnikov wrote:
Exactly. Classes are not about just the class keyword, but about
the _ability to classify_, i.e. to program in classified (i.e. with
object-patterned programming). JS supports (and supported
On 28.03.2011 0:05, Brendan Eich wrote:
On Mar 27, 2011, at 11:33 AM, Juan Ignacio Dopazo wrote:
On Sat, Mar 26, 2011 at 6:31 PM, Dmitry A. Soshnikov
dmitry.soshni...@gmail.com mailto:dmitry.soshni...@gmail.com wrote:
Why not just to use already reserved `extends` keyword
On 27.03.2011 22:33, Juan Ignacio Dopazo wrote:
On Sat, Mar 26, 2011 at 6:31 PM, Dmitry A. Soshnikov
dmitry.soshni...@gmail.com mailto:dmitry.soshni...@gmail.com wrote:
Why not just to use already reserved `extends` keyword for
specifying a superclass? These XML-like braces looks
Hi,
Just a small note on
http://wiki.ecmascript.org/doku.php?id=strawman:super_in_object_initialisers
(reading currently)
Why not just to use already reserved `extends` keyword for specifying a
superclass? These XML-like braces looks not so elegant.
Coffee users the same classes syntactic
On 24.03.2011 0:44, Brendan Eich wrote:
On Mar 23, 2011, at 12:57 PM, Dmitry A. Soshnikov wrote:
Yep, I see. Btw, JFTR: such a mistake currently is in this strawman
http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax:
let randomArray = Array(10).map(#{Math.random
On 24.03.2011 0:44, Brendan Eich wrote:
On Mar 23, 2011, at 12:57 PM, Dmitry A. Soshnikov wrote:
Yep, I see. Btw, JFTR: such a mistake currently is in this strawman
http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax:
let randomArray = Array(10).map(#{Math.random
On 23.03.2011 0:18, David Bruant wrote:
Le 22/03/2011 02:39, Dmitry A. Soshnikov a écrit :
On 22.03.2011 23:42, David Bruant wrote:
Hi,
About the string_repeat strawman
(http://wiki.ecmascript.org/doku.php?id=strawman:string_repeat), one
alternative solution could be a two argument
JFTR, I remember the previous the same discussion(s) and mentioned
earlier the thing similar to this `Object.subclass`, though, just with
providing an ability to specify the [[Class]] for `Object.create`. E.g.
for a unclassified inheritance:
let foo = Object.create(Array.prototype, Array,
1 - 100 of 186 matches
Mail list logo
