On Nov 12, 2011, at 12:02 PM, Brendan Eich wrote:
On Nov 12, 2011, at 2:07 AM, Axel Rauschmayer wrote:
Embedded spreads is already in the ES6 draft for both array literals and
argument lists. I'm not at all sure that embedded rests in destructurings
are such a good idea.
I think it
(I'm going to write this up as a strawman, this list gets first shot at it...)
Introduction
For ES.next we all want to provide better ways for ES programers to define
named abstractions over objects. One way to do this that we have discussed is
Object exemplars
On Nov 14, 2011, at 12:28 PM, Brendan Eich wrote:
Quick reply to say two things:
1. I like the more radical approach (need to ruminate on it more). Usability
remains my concern for classes as sugar (the Cordova edition).
2. Credit to Russell Leggett for posting this idea (I'm pretty
On Nov 14, 2011, at 1:06 PM, Axel Rauschmayer wrote:
This is the middle ground between class proponents and object exemplar
proponents, right?
Yes, next up is to write-up a stawman that ties all the pieces together into a
rational story/
- Object exemplar proponents get object literal
On Nov 14, 2011, at 1:15 PM, Axel Rauschmayer wrote:
The class operator can prefix any UnaryExpression, not just object
literals. That means that the class operator can be used to classify
objects:
if (class p === Point) ...
Note that many object-oriented abstraction designers
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 added property reference
let p = new
On Nov 14, 2011, at 3:09 PM, Axel Rauschmayer wrote:
The concept of a constructor function being the class of an object is one
of those things that has been around JS apparently from the beginning. It
just didn't have a suggestively named operator. However an object is
instantiated,
On Nov 14, 2011, at 3:15 PM, David Flanagan wrote:
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
On Nov 14, 2011, at 4:05 PM, Jake Verbaten wrote:
UnaryExpression :
class UnaryExpression
...
The semantics are:
1. if UnaryExpression is undefined or null, return the value of
UnaryExpression.
2. Let obj be ToObject(UnaryExpression)
3. Return the result of
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. If we can have two different types of classes, we're
On Nov 15, 2011, at 8:16 AM, Russell Leggett wrote:
...
As has been said, a missing constructor would not result in the expected
behavior. I can also imagine other scenarios where the behavior would be
unusual.
I agree, there is an issue with missing constructors. Certainly my
OK, I have a fix for the missing constructor problem. See:
http://wiki.ecmascript.org/doku.php?id=strawman:class_operator#missing_constructors
Allen
On Nov 15, 2011, at 9:25 AM, Allen Wirfs-Brock wrote:
On Nov 15, 2011, at 8:16 AM, Russell Leggett wrote:
...
As has been said
On Nov 17, 2011, at 9:47 AM, Jake Verbaten wrote:
5 Let proto be the value of the [[Prototype]] internal property of obj.
6 Return the result of evaluating this algorithm using the value of proto as
the value of UnaryExpression
What is the point of calling class recursively on the
On Nov 17, 2011, at 2:05 PM, Brendan Eich wrote:
On Nov 17, 2011, at 9:04 AM, Allen Wirfs-Brock wrote:
OK, I have a fix for the missing constructor problem. See:
http://wiki.ecmascript.org/doku.php?id=strawman:class_operator#missing_constructors
Nit: [[ctor]], obviously a temporary
On Nov 17, 2011, at 3:47 PM, Jake Verbaten wrote:
On Thu, Nov 17, 2011 at 11:39 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 17, 2011, at 3:31 PM, Allen Wirfs-Brock wrote:
We can debate whether Default Constructors should do a:
if (super.constructor isnt Object
On Nov 17, 2011, at 11:21 AM, Russell Leggett wrote:
sorry that last one didn't go to the group - ignore. This new gmail interface
screwed me up ;)
On Thu, Nov 17, 2011 at 2:20 PM, Russell Leggett russell.legg...@gmail.com
wrote:
At this point, if Allen's proposal included a
I updated the strawman with a declaration form of the class operator:
http://wiki.ecmascript.org/doku.php?id=strawman:class_operator#a_binding_declaration_form
the strawman is somewhat different from what I described below.
Allen
On Nov 17, 2011, at 5:51 PM, Allen Wirfs-Brock wrote:
On Nov
metaIn the following I'm going to use syntax from by class operator strawman:
http://wiki.ecmascript.org/doku.php?id=strawman:class_operator However, the
basic idea should be applicable to several of the class declarations proposal
that are drifting about.
BTW, I'm pretty sure that this isn't
On Nov 20, 2011, at 10:03 AM, Brendan Eich wrote:
On Nov 20, 2011, at 8:12 AM, Rick Waldron wrote:
Ah, yes and agreed. That was definitely not relayed in the message below-
thanks for the clarification, the context does make a difference.
Destructuring parameters + default values really
On Nov 20, 2011, at 8:30 PM, Brendan Eich wrote:
On Nov 20, 2011, at 1:18 PM, David Herman wrote:
I would not add more implicit magic to JS. E4X had junk like this in it,
which only ever concealed bugs.
I'm of two minds about this. In the abstract, I agree with Brendan;
fail-soft
On Nov 20, 2011, at 8:30 PM, Brendan Eich wrote:
On Nov 20, 2011, at 1:18 PM, David Herman wrote:
I would not add more implicit magic to JS. E4X had junk like this in it,
which only ever concealed bugs.
I'm of two minds about this. In the abstract, I agree with Brendan;
fail-soft
On Nov 19, 2011, at 11:38 AM, Dean Landolt wrote:
On Sat, Nov 19, 2011 at 1:57 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Nov 15, 2011, at 10:27 PM, Russell Leggett wrote:
but given the overall disapproval of the exact syntax of the | operator, I
think its
On Nov 22, 2011, at 10:14 AM, Brendan Eich wrote:
On Nov 22, 2011, at 9:37 AM, Allen Wirfs-Brock wrote:
...
Unfortunately, as it now stands you have to use the implementation
dependent message property value to actually identify specific exceptions.
*Error.prototype.name
On Nov 22, 2011, at 10:54 AM, Bob Nystrom wrote:
On Tue, Nov 22, 2011 at 10:41 AM, Brendan Eich bren...@mozilla.com wrote:
Nothing there about arrays or regular expressions, and the function examples
do *not* show anything like
superFun | function (...) {...}
Instead of Ahem'ing,
On Nov 26, 2011, at 11:52 AM, David Bruant wrote:
Le 24/11/2011 22:29, Tom Van Cutsem a écrit :
2011/11/24 Allen Wirfs-Brock al...@wirfs-brock.com
If we are going to have a @reflection module that is of broader
applicability then just writing proxy handlers I'd like us to consider
On Nov 29, 2011, at 3:58 PM, Brendan Eich wrote:
...
So don't check, let the program fail.
The problem with the latter (i.e., with [doing] its best to extend the
object is that you could end up with a bad combination of old and new
properties.
There's no silver bullet here. If we want
On Nov 30, 2011, at 9:06 AM, David Herman wrote:
On Nov 22, 2011, at 10:14 AM, Brendan Eich wrote:
On Nov 22, 2011, at 9:37 AM, Allen Wirfs-Brock wrote:
Range error actually has fairly limited usage in the current specification.
Enough so, that it arguably doesn't carry its weight
On Nov 30, 2011, at 10:24 AM, David Bruant wrote:
Le 29/11/2011 23:07, Allen Wirfs-Brock a écrit :
...
Objects serve as one of our primary abstraction mechanisms (the other is
functions and function closures have similar allocation issues). Anytime you
you tell programmers
On Dec 28, 2011, at 11:58 AM, gaz Heyes wrote:
I'd also like to add that __proto__ allows valid JSON to change it's object
type and allow functions within properties. There isn't a compelling exploit
scenerio for this yet but who knows what is possible if setters come into the
equation.
On Dec 27, 2011, at 10:29 AM, David Bruant wrote:
Le 27/12/2011 19:14, Mark S. Miller a écrit :
On Tue, Dec 27, 2011 at 7:15 AM, David Bruant bruan...@gmail.com wrote:
...
That's what I wish. JS already has name-based polymorphism (as is typical of
scripting languages). Generic methods,
On Dec 27, 2011, at 10:20 AM, Mark S. Miller wrote:
Hi Axel, yes, I would like to extend their constructor in this way. However,
I'm not sure how to spec it -- help appreciated. The problem is that the
comparator needs to provide both an equivalence operation and a corresponding
hash
On Dec 28, 2011, at 5:36 PM, Mark S. Miller wrote:
Comments on this proposal appreciated.
Mark,
Your proposal doesn't address the occurrence of __proto__ as a property name in
an object literal
Allen
___
es-discuss mailing list
On Dec 29, 2011, at 6:34 AM, Axel Rauschmayer wrote:
We should probably avoid pressures for the build-ins to cover all possible
use cases. In ES.next we will should have all the primitives necessary for
JS programmers to define their own efficient collection objects, including
various
On Dec 29, 2011, at 3:38 AM, Lasse Reichstein wrote:
There is one side-effect to defining __proto__ using a getter/setter
property. You can extract the setter and store it for later, allowing
you to change the prototype of objects after someone else deleted the
__proto__ property.
Not if
On Dec 28, 2011, at 10:14 PM, Mark S. Miller wrote:
On Wed, Dec 28, 2011 at 10:06 PM, Brendan Eich bren...@mozilla.com wrote:
From: Mark S. Miller erig...@google.com
I take it you are simply reiterating the desire for a standard system
provided high entropy object-identity hash that is
On Dec 28, 2011, at 6:48 PM, Mark S. Miller wrote:
...
Likewise, I expect that detecting misbehavior sort comparison functions is
too hard to be practical. However, I strongly disagree that the current
underspecification isn't a problem. How undefined is this behavior?
(Actually, the
On Dec 29, 2011, at 2:00 PM, David Bruant wrote:
Le 29/12/2011 18:13, Allen Wirfs-Brock a écrit :
On Dec 29, 2011, at 4:58 AM, David Bruant wrote:
Le 29/12/2011 03:04, Mark S. Miller a écrit :
Darn. I completely missed that. No easy fix comes to mind. Suggestions?
I think '__proto__
On Jan 1, 2012, at 5:54 AM, Axel Rauschmayer wrote:
http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation
Currently, there one can override the built-in operators via elementGet
(getting via []), elementSet (setting via []) and elementDelete (`delete`
operator).
On Jan 3, 2012, at 12:01 PM, Brendan Eich wrote:
On Jan 3, 2012, at 1:29 AM, Andreas Rossberg wrote:
...
For multi-part scripts we need a way to switch the
_proper_ top-level into extended mode. Or should I not be able to
write (the relevant bits of) a multi-part script in extended
On Jan 3, 2012, at 4:31 PM, Gavin Barraclough wrote:
On Jan 3, 2012, at 3:27 PM, Brendan Eich wrote:
You're proposing that we require 'let' be only at the start of statements?
If so, then destructuring is problematic:
foo();
let [x] = y;
Did that last line destructure the property
On Jan 3, 2012, at 4:42 PM, Brendan Eich wrote:
On Jan 3, 2012, at 4:38 PM, Allen Wirfs-Brock wrote:
ArrayBindingPattern :
[ Elisionopt BindingRestElementopt ]
[ BindingElementList , Elisionopt BindingRestElementopt ]
It's a grammar bug. Thanks for the proof reading
On Jan 4, 2012, at 4:23 AM, Andreas Rossberg wrote:
...
- Despite the superficial fewer modes mantra, it actually doesn't
make the language simpler, but more complicated: instead of defining
the semantics for Harmony features only for strict-mode programs, we
now have to define many
On Jan 4, 2012, at 8:39 AM, Mark S. Miller wrote:
...
Here's an interesting compromise I consider perfectly reasonable. We don't
*mandate* any ES6 code features be available in ES6 non-strict mode. But we
don't prohibit them either. For any ES6 features that have no dependence on
mode,
On Jan 4, 2012, at 12:16 PM, Brendan Eich wrote:
...
Any new Harmony syntax that presents no backward incompatibility *and* has a
body opts the body into the new edition, a superset of ES5-strict.
Including expression level bodies such a block lambda's or Dave's do { }
expressions, if
As it stands right now there are still other more significant outstanding
issues relating to both proposals that need to be addressed. As those get
resolved we will make then as consistent with each other as makes sense. I
think there is wide agreement that methods should be should be
On Jan 4, 2012, at 11:38 PM, Mark S. Miller wrote:
In your suggestion, when an occurrence of destructuring (or any other new
syntax) is seen, what unit of code is then opting in to strict? Would it be
the nearest enclosing function, module, class, generator, or Program? I think
I'm
Here is a possible set of rules for implicitly assigning ES5 or ES6 semantics
to a Program unit
In an ES6 implementation, all constructs that can occur in a valid program
fit into one of these categories:
ES6-only: The construct is based upon syntax or static semantics rules that
only exist
strict code.
Allen
On Thu, Jan 5, 2012 at 6:37 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
Here is a possible set of rules for implicitly assigning ES5 or ES6 semantics
to a Program unit
In an ES6 implementation, all constructs that can occur in a valid program
fit into one
On Jan 5, 2012, at 10:20 PM, Mark S. Miller wrote:
On Thu, Jan 5, 2012 at 10:13 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jan 5, 2012, at 8:24 PM, Mark S. Miller wrote:
Hi Allen, if ES5 had only one mode, I'd understand this. But I thought we
were trying to arrive
On Jan 5, 2012, at 10:38 PM, Luke Hoban wrote:
...
# Why ‘implicit explicit opt-in’ doesn’t seem reasonable #
The prevalent alternatives presented in this thread are variations of
“implicit explicit opt-in”, where use of some new syntax causes some part of
the code inside or outside
On Jan 6, 2012, at 12:00 AM, Mark S. Miller wrote:
On Thu, Jan 5, 2012 at 11:47 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
1) program using only ES3 features and no use strict;
2) program using only ES5 strict features and saying use strict;
3) program using ES6
On Jan 6, 2012, at 8:03 AM, Mark S. Miller wrote:
No sorry, I just spotted the flaw. The observable difference is that a
conforming browser is not required by the (ES5 + ES6) specs to provide any
non-triggering ES6 features for program #2. In that case, we again have three
mode.
For
On Jan 6, 2012, at 11:23 AM, Mark S. Miller wrote:
AFAICT, this agrees with my analysis of what your proposal means. How does
this not result in three modes?
I guess I don't understand exactly what you mean by a mode or why the number
of modes is particularly interesting.
From an
On Jan 6, 2012, at 11:52 AM, Brendan Eich wrote:
(This grew out of a conversation Allen and I had yesterday -- great to see it
developed.)
One thing to make clear:
ES5~EAS6: The construct has identical syntax and static semantics in both
ES5 and ES6, but differing semantics. For
On Jan 8, 2012, at 9:26 PM, Brendan Eich wrote:
On Jan 8, 2012, at 4:53 PM, Mark S. Miller wrote:
On Sun, Jan 8, 2012 at 10:32 AM, Brendan Eich bren...@mozilla.com wrote:
[...]
All cool with the above. Thanks.
I wrote in a previous reply that we aren't preserving ES5 as a spec
On Jan 8, 2012, at 10:32 AM, Brendan Eich wrote:
On Jan 8, 2012, at 8:28 AM, Mark S. Miller wrote:
...
The other change I hope fits into the same bucket is
http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake.
Right now, because of pressure from test262, we are in
On Jan 11, 2012, at 10:10 AM, John J Barton wrote:
The blog post http://yehudakatz.com/2012/01/10/javascript-needs-blocks/
makes the case for blocks that act like functions when passed as arguments
but have loop-up rules more like nested blocks.
Of course these are called 'block
On Jan 11, 2012, at 2:11 PM, Mark S. Miller wrote:
How about first class blocks or callable blocks?
I also suggest callable blocks in a private email. Also a couple of others:
functional block and block function.
I like callable blocks in that it emphasizes the block-ness (and
On Jan 12, 2012, at 1:26 PM, Thaddee Tyl wrote:
I have heard many fellow programmers say that, while block lambdas
would be welcome, Ruby's |a, b| syntax is ugly.
I thought I was the only one feeling this way, but since I am not, I
would like to ask why the parentheses cannot be used there.
On Jan 12, 2012, at 2:23 PM, François REMY wrote:
Am I wrong if I say there not a bigger issue with block lambda than with the
current object notation on the matter?
I think you're correct. An ExpressionStatment can not begin with a {
so,without changing that rule, there should be no
On Jan 13, 2012, at 6:09 AM, john saylor wrote:
hello world!
On 01/12/2012 09:09 PM, David Herman wrote:
It does help to write a reasonable chunk of code to compare syntaxes for
uses of a feature in the wild. Does some enterprising es-discusser wanna
take a big JS program with a bunch
On Jan 14, 2012, at 9:12 AM, David Herman wrote:
On Jan 13, 2012, at 9:04 PM, Axel Rauschmayer wrote:
I think it’s a valid concern. The idea is: If I can implement my own loops
(the nice-looking paren-free syntax feeds that illusion!) then I also want
those loops to have break and
On Jan 14, 2012, at 6:46 PM, Brendan Eich wrote:
Adding escape continuations is another case of warty + shiny ~~~ shiny
promised land hope as the evolutionary game we have to play on the web.
Still, I'm in favor of escape continuations but I do not want to bundle them
with block-lambdas.
On Jan 15, 2012, at 8:10 AM, David Bruant wrote:
Hi,
I'm refering to Allen's writing at [1]:
The basic idea is that the properties prototype object are shared
parts of all of inheriting child object. Modifying such a shared part
by a child, introduces a local change that is visible to
On Jan 15, 2012, at 11:56 AM, Brendan Eich wrote:
Grant Husbands
January 15, 2012
8:00 AM
The
above would desugar to:label1:
arr.forEach { |o| if (...) break label1;}If it had continue instead of
break, it would desugar to:arr.forEach
{ |o| label2: {
if (...)
On Jan 16, 2012, at 11:09 AM, Brendan Eich wrote:
With completion values as In ES1-5, not even depending on
http://wiki.ecmascript.org/doku.php?id=harmony:completion_reform, it might be
enough to say:
You're right, according to ES 5 semantics this does provide early as the
value of the
One of the thing that an ES6 (or extended code as it is currently known in
the ES6 draft) mode that is distinct from strict mode does is allow us do
add additional Early Errors that aren't in ES5 for various existing constructs.
It isn't clear that we could continue to have add these errors
I think mode terminology is quite misleading, particularly in regard to run
time semantics. For Es5 (and I believ es6) there is no need of for a global
runtime mode bit that is analagous to a cpu mode bit that ambiently changes the
semantics of some or all instruction. Instead, we have
Most of the extended code early errors I list in a previous message on this
thread are examples of changes that are not backward compatable with Es5 strict
code that Axel is talking about belowAxel Rauschmayer a...@rauschma.de
wrote:Ss1. module = ES6 – some changes break with ES5.strict
some
An updated draft is available at the usual place
(http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts )
That draft incorporated decisions made at the Nov. 2011 TC39 meeting. However,
note that this draft also contains a significant amount of still in flight
work.
On Jan 17, 2012, at 3:45 AM, Herby Vojčík wrote:
Brendan Eich wrote:
Clearly(!) a set-if-not-present method should not be misnamed get.
I like the optional sentinel-meaning-not-found for get, and setDefault
per Python as Tab pointed out. Agree they should not be merged into one
API.
On Jan 16, 2012, at 7:45 PM, Norbert Lindenberg wrote:
On Dec 8, 2011, at 10:25 , Nebojša Ćirić wrote:
Proposed changes to the original API:
[snip]
2a. What happens with toLocaleString methods when user doesn't load
@globalization module?
I think they should work as specified in the
On Jan 17, 2012, at 10:14 AM, Grant Husbands wrote:
Allen Wirfs-Brock wrote:
do: arr.alternate ({|o| if (...) continue; if (...) break; ...}, {|o| if
(...) continue; ...});
I don't see how this can support the most likely intended semantics
I think others might have better answers
On Jan 20, 2012, at 6:22 AM, Herby Vojčík wrote:
Andreas Rossberg wrote:
On 20 January 2012 01:40, Waldemar Horwatwalde...@google.com wrote:
Also, function (e) {let e;} should always be an error.
Is there a good reason to do this? It would be an unnecessary
irregularity with block
On Jan 20, 2012, at 7:13 AM, Wes Garland wrote:
On 20 January 2012 09:22, Herby Vojčík he...@mailbox.sk wrote:
+1. I see no point why let e; should not shadow argument e here.
I do. It is a virtual certainty that this form was used accidentally by the
developer, which indicates a flaw
On Jan 20, 2012, at 10:22 AM, Brendan Eich wrote:
Mark S. Miller mailto:erig...@google.com
January 20, 2012 10:15 AM
On Fri, Jan 20, 2012 at 9:57 AM, Herby Vojčík he...@mailbox.sk
mailto:he...@mailbox.sk wrote:
Single scope, args are lets view is making sense of this. Ok,
On Jan 20, 2012, at 10:19 AM, Andreas Rossberg wrote:
On 20 January 2012 18:28, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Jan 20, 2012, at 7:13 AM, Wes Garland wrote:
On 20 January 2012 09:22, Herby Vojčík he...@mailbox.sk wrote:
+1. I see no point why let e; should
On Jan 20, 2012, at 5:55 AM, Andreas Rossberg wrote:
From the TC39 notes:
DaveH: What if there are duplicate top-level bindings?
MarkM: Top-level let should behave as much as possible the same as
concatenated scripts.
It's my claim that it is impossible to reconcile all of the following
On Jan 20, 2012, at 5:08 PM, Brendan Eich wrote:
...
(Aside: I wish I had used fn instead of function in 1995!)
At the TC39 meeting we were trying to think of pragma candidates.
It wouldn't surprise me if JS programmer would happily trade one:
use fn;
per file in exchange for being able
On Jan 21, 2012, at 12:25 AM, Andreas Rossberg wrote:
On 21 January 2012 01:23, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Temporal dead-zone initialization tracking requires extra state and checking
(except for the common cases within functions where it can be statically
determined
On Jan 22, 2012, at 11:58 AM, Jake Verbaten wrote:
Most of the time the purpose of deep cloning objects is deep cloning data
structures.
It's been discussed that generically deep cloning proxies, privates and
functions is a non-trivial problem.
However it would be of value to have a
On Jan 22, 2012, at 11:58 AM, Jake Verbaten wrote:
Most of the time the purpose of deep cloning objects is deep cloning data
structures.
It's been discussed that generically deep cloning proxies, privates and
functions is a non-trivial problem.
However it would be of value to have a
On Jan 21, 2012, at 12:07 PM, Brendan Eich wrote:
This was already proposed. See the whole strawman, but in particular these
sections:
http://wiki.ecmascript.org/doku.php?id=strawman:private_names#the_private_declaration
Below...Brendan Eich bren...@mozilla.org wrote: Allen Wirfs-Brock
mailto:al...@wirfs-brock.com
January 23, 2012 8:43 AM
On Jan 22, 2012, at 7:36 PM, Tab Atkins Jr. wrote:
?..
const getIterator = Iterator.getIterator;
myCoolObject.prototype.@getIterator = function() {...}
Why wouldn't
I think I'm largely in agreement with what you were saying below, but I do have
some additional thoughts I added below...
On Jan 23, 2012, at 11:28 AM, Brendan Eich wrote:
Brendan Eich mailto:bren...@mozilla.org
January 23, 2012 11:08 AM
We run into this kind of trade-off all the time, but
On Jan 23, 2012, at 1:14 PM, Herby Vojčík wrote:
Axel Rauschmayer wrote:
Losing generic [] as a way to access all native properties of the
object is big price.
I wonder if it really is such a big price: isn’t [] mainly used for
objects as maps from strings to values? Then you should use
On Jan 23, 2012, at 7:43 PM, Axel Rauschmayer wrote:
Also, the square bracket preference also currently shows up in the object
literal computed property key proposal so we already have
obj[privateNameValue] pattern manifesting itself as new ES6 syntax.
Would [] in object literals still
On Jan 24, 2012, at 12:35 PM, Axel Rauschmayer wrote:
Reiterating my support for the reformed object model (ROM): I love how the
ROM will finally end the clashes between application data (array elements,
entries in objects-as-maps) and program definition (methods, non-method
properties).
On Jan 24, 2012, at 2:11 PM, Mark S. Miller wrote:
On Tue, Jan 24, 2012 at 12:33 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
Note that this proposal isn't currently under consideration for inclusion in
ES.next, but the answer to you question is below
[...]
Just as the current
On Jan 24, 2012, at 11:45 PM, Norbert Lindenberg wrote:
I don't see the standard allowing character encodings other than UTF-16 in
strings. Section 8.4 says When a String contains actual textual data, each
element is considered to be a single UTF-16 code unit. This aligns with
other
On Jan 25, 2012, at 9:54 AM, John Tamplin wrote:
On Wed, Jan 25, 2012 at 12:46 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
Arbitrary 16-bit values can be placed in a String using either
String.fromCharCode (15.5.3.2) or the \u notation in string literals.
Neither
On Jan 25, 2012, at 11:37 AM, John Tamplin wrote:
On Wed, Jan 25, 2012 at 2:33 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
It isn't clear from your source code what encoding issues you have actually
identified. I suspect that you are talking about what happens when an
external
On Jan 25, 2012, at 10:59 AM, Gillam, Richard wrote:
The current 16-bit character strings are sometimes uses to store non-Unicode
binary data and can be used with non-Unicode character encoding with up to
16-bit chars. 21 bits is sufficient for Unicode but perhaps is not enough
for other
On Jan 25, 2012, at 12:25 PM, John Tamplin wrote:
On Wed, Jan 25, 2012 at 2:55 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
The primary intent of the proposal was to extend ES Strings to support a
uniform represent of all Unicode characters, including non-BMP. That means
that any
The following proposal questions the validity of the teeshirt maxim Let is the
new var as a rationale for treating global |let| declarations similarly to
ES=5 global |var| declarations. While we want people to use |let| (and
|const|) in preference to |var| we don't want to unnecessarily
On Jan 25, 2012, at 3:47 PM, Andrea Giammarchi wrote:
Number.prototype.pow = function pow(radix) {
return Math.pow(this, radix);
};
//alert(2.pow(3)); // error, decimal point, not property accessor
alert(2..pow(3)); // 8
alert(NaN.pow(0)); // 1
The last case is strictly in
On Jan 26, 2012, at 11:51 AM, Brendan Eich wrote:
Andreas Rossberg mailto:rossb...@google.com
January 26, 2012 11:26 AM
...
I still like the idea of cross-script shadowing (aka nested scopes),
but one concern was that it is not clear what names would be in scope
for, say, a piece of JS
On Jan 26, 2012, at 11:26 AM, Andreas Rossberg wrote:
On 26 January 2012 17:47, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Jan 26, 2012, at 3:01 AM, Andreas Rossberg wrote:
Overlapping imports? That's the first time I hear about that. That
might be rather difficult, given that modules
On Jan 27, 2012, at 8:38 AM, Luke Hoban wrote:
JS REPLs tend to parse input as Program productions. Parsing {} + {} as a
block followed by a unary expression is correct according to ES5 grammar for
Program. IE behaves the same.
It's not just in Program, it's any statement context.
On Jan 27, 2012, at 9:59 AM, Rick Waldron wrote:
On Fri, Jan 27, 2012 at 12:08 PM, Brendan Eich bren...@mozilla.org wrote:
[[Class]] begone in ES6.
Assuming the public facing API has no intention of breaking back
compatibility, what internal property will be read to determine the return
701 - 800 of 2846 matches
Mail list logo
