<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.lang.javascript.ecmascript4.general">
    <title>gmane.comp.lang.javascript.ecmascript4.general</title>
    <link>http://blog.gmane.org/gmane.comp.lang.javascript.ecmascript4.general</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18554"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18549"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18539"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18538"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18535"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18528"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18523"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18519"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18501"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18497"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18491"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18488"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18473"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18472"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18467"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18466"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18465"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18461"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18455"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18453"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18554">
    <title>Array.prototype.search</title>
    <link>http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18554</link>
    <description>&lt;pre&gt;Hello,

I've been playing around with an iterative array method I wrote earlier
today. I thought it would be a good idea to post it here and see wher

The idea behind this method is to search for the best match. It does this
by allowing you to specify a weighing function that calculates the best
result based by comparing two of the values at a time.

Here is a variant to the method I have been toying with:


Array.prototype.search = function( searchFn, scope ){
var len = this.length, i = 1, curr;

if(len === 0){ throw new TypeError("Length is 0 and no results are
possible."); }

curr = this[0];

for( ; i &amp;lt; len; i++ ) {
if( i in this &amp;amp;&amp;amp; searchFn.call( scope, curr, this[i], i, this ) ) {
curr = this[i];
}
}

return curr;
};


For an example say you have a list of coordinates and you want to get the
largest x coordinate you would just do something like this:

var arr = [
{ x: 0, y: 124 },
{ x: 50, y: 34 },
{ x: -23, y: 85 },
{ x: 163, y: 40 },
{ x: 65, y: -20 }
];

arr.search( function(c,v,i,o){
return v.x &amp;gt; c.&lt;/pre&gt;</description>
    <dc:creator>Rich Walrath</dc:creator>
    <dc:date>2012-05-26T04:26:13</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18549">
    <title>Arity checking?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18549</link>
    <description>&lt;pre&gt;I was under the impression that ECMAScript.next was going to perform arity checking. But looking at the proposals and the draft spec, it doesn’t look like it.

I can see pros and cons either way. I take it that the rationale was to not do things too differently(?) It would indeed be weird to perform arity checking only in the presence of parameter default values and/or rest parameters. Conditionally switching it on (e.g. via a pragma) does seem an option, though.

&lt;/pre&gt;</description>
    <dc:creator>Axel Rauschmayer</dc:creator>
    <dc:date>2012-05-25T07:21:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18539">
    <title>Array.prototype.take</title>
    <link>http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18539</link>
    <description>&lt;pre&gt;Hi, 

At the moment Array methods can do almost everything that one can do with plain `for` iteration, only missing piece is `break`. 
Is there any chance to get something like:

array.take(predicate) 

Although, `take` would be way more useful if array methods chains were applied lazily. So that:

array.filter(predicate).map(fn).take(once) would only call `fn` up to a first match.

Maybe `Array.prototype.take` is not a best fit, but would be great if we could get at least something to cover
lack of `break`.

Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/

_______________________________________________
es-discuss mailing list
es-discuss-4eJtQOnFJqFAfugRpC6u6w&amp;lt; at &amp;gt;public.gmane.org
https://mail.mozilla.org/listinfo/es-discuss
&lt;/pre&gt;</description>
    <dc:creator>Irakli Gozalishvili</dc:creator>
    <dc:date>2012-05-25T00:42:43</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18538">
    <title>Generators improvement idea</title>
    <link>http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18538</link>
    <description>&lt;pre&gt;Hi, 

I have an improvement suggestion for generators. Unless I'm mistaken in spider monkey you
`yield` maybe used as a function:

function g() {
 yield(1)
 yield(2)
}


for (let $ in g()) console.log($)


It would be cool to take this even further and let users give `yield` a context specific name. 


// yield is passed in
function* program(require) {
  // maybe even alias passed in yield 
  var use = require;

  var _ = require('underscore')
  var template = require('asset!./template.html')
  var data = require('asset!./model.json')

  document.body.innerHTML = _.template(template, data) 
}

This would loading all assets async but avoid callbacks 

This is idea came to mind while thinking how SDK APIs that users commonly complain
about can be improved (At the moment it web worker like). There are some more examples

in the "more thoughts" section of the following document:
https://github.com/mozilla/addon-sdk/wiki/JEP-Content-scripts

Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/

_______&lt;/pre&gt;</description>
    <dc:creator>Irakli Gozalishvili</dc:creator>
    <dc:date>2012-05-25T00:29:28</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18535">
    <title>"strict mode" |with| proposal</title>
    <link>http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18535</link>
    <description>&lt;pre&gt;Draft is here : https://gist.github.com/edd064e5b29e67ebe493

Maybe everything is not accurate regarding some comments and annex 
should include other examples but, before writing more, let's submit it

As mentionned in the gist, it is supposed to address several topics : 
security and wrapping, modules, multiple globals, VMs and proxies

It did not come up just this morning, it can be called a |with| 
"nothing" proposal, |with| is not light in specs and rarely used, it was 
eliminated in strict mode (even if some non strict/strict mode 
combinations use it, see recent cajaVM analysis) but maybe strict mode 
can give it another meaning.

The concept is simple and based on the implementation of VMs where if 
you have to pass something to |with| or other, then it's totally 
impossible to separate it completely from the initial scope (see annex)

There is a disruptive assignment floating in the |with|'s code : 
"this=window" (which then sets the ThisBinding and associated var 
bindings), which has to follow som&lt;/pre&gt;</description>
    <dc:creator>Aymeric Vitte</dc:creator>
    <dc:date>2012-05-24T21:22:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18528">
    <title>const classes for max/min</title>
    <link>http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18528</link>
    <description>&lt;pre&gt;Waldemar has put a pretty firm line in the sand regarding the need for a
higher integrity class construct. While I would love to start by agreeing
on max/min as a safety syntax and iterating forward, I appreciate the
desire for such a construct and would probably use it myself. It seems to
me that one of the big reasons for Dart's version of classes is to enforce
this type of integrity. Certainly, it would be useful. The questions is:
how hard would it be to get it to work well this max/min as the base.
Waldemar conceded that he was even fine with const not being the default,
which would have been a much bigger problem. After looking over the const
class section of the harmony class
proposal&amp;lt;http://wiki.ecmascript.org/doku.php?id=harmony:classes#const&amp;gt;and
realized that it could work almost exactly the same. The big thing I
wanted to avoid, though was the public keyword. This is what I came up with
for making a const Monster class from the max/min proposal:

    // a private name used by the Monster class
   &lt;/pre&gt;</description>
    <dc:creator>Russell Leggett</dc:creator>
    <dc:date>2012-05-24T19:07:07</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18523">
    <title>announcing normative ECMAScript specification in HTML</title>
    <link>http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18523</link>
    <description>&lt;pre&gt;Ecma International now hosts a normative HTML copy of Ecma-262, Edition 5.1  The ECMAScript Language Specification.  The document includes a hyperlinked table of contents and supports external linking to  sections listed in the table of contents.

The document may be accessed at http://ecma-international.org/ecma-262/5.1 

This is a permalink to this specific edition.  It should be used in any situations where there is a need to link to the normative version of the ECMAScript 5.1 specification. Future editions will received their own edition specific  links.  

A big thanks to Jason Orendorff for his essential contributions to  the production of this HTML version of the specification.

Happy linking,

Allen Wirfs-Brock
Ecma-262 Project Editor_______________________________________________
es-discuss mailing list
es-discuss-4eJtQOnFJqFAfugRpC6u6w&amp;lt; at &amp;gt;public.gmane.org
https://mail.mozilla.org/listinfo/es-discuss
&lt;/pre&gt;</description>
    <dc:creator>Allen Wirfs-Brock</dc:creator>
    <dc:date>2012-05-24T17:58:16</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18519">
    <title>Clarification of [[Prototype]] of Intl.Collator.prototype</title>
    <link>http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18519</link>
    <description>&lt;pre&gt;Hello everyone,

In lastest i18n draft, Intl.Collator.prototype is defined in section 11.2.1

The value of Intl.Collator.prototype is the built-in Intl.Collator


and section 11.3

The Intl.Collator prototype object is itself an Intl.Collator instance as

whose internal properties are set as if it had been constructed by the


But this is ambiguous about prototype's [[Prototype]].
Intl.NumberFormat.prototype and Intl.DateTimeFormat.prototype have the same
problem.
For example, I found a curious point in test262 intl tests,
intl402/ch11/11.3/11.3.js.

var testcase = function() {
  "use strict";

  if (!(Intl.Collator.prototype instanceof Intl.Collator)) {
    $ERROR("Intl.Collator's prototype is not an instance of " +
           "Intl.Collator");
  }

  return true;
}
runTestCase(testcase);


If this test case is passed, chain starting from
Intl.Collator.prototype.[[Prototype]] get to Intl.Collator.prototype.
And this is circular reference, so following script

var collator = new Intl.Collator();
collator.toS&lt;/pre&gt;</description>
    <dc:creator>Yusuke Suzuki</dc:creator>
    <dc:date>2012-05-24T12:49:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18501">
    <title>TC39 meeting Wed 5/23/2012</title>
    <link>http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18501</link>
    <description>&lt;pre&gt;# Override Mistake (Allen Wirfs-Brock, Mark Miller)

AWB:
- The correct people are not here for this discussion, defer to next meeting


# 4.14, Unicode (Norbert Lindenderg)

NL:
- Regular expressions
- Certain unclear, discuss with Unicode Consortium
see:
http://norbertlindenberg.com/2012/05/ecmascript-supplementary-characters/index.html

http://norbertlindenberg.com/2012/05/ecmascript-supplementary-characters/full-unicode-in-ecmascript.pdf

AWB:
- Concretely, should supplementary characters gain coverage in the
currently developing draft.

MM:
- Mention of spec modularity

AWB:
- Implication for strings etc.

NL, LH, MM:
- Any objections? No.


AWB:
- Canonicalize everything to full unicode grammar
- Don't think this will change implementation rules

LH:
- Asks for confirmation

NL, AWB:
- Confirms no difference.

Resolution: Promoted unanimously to harmony status


# 4.11, Daylight Savings (Luke Hoban)

Move to remove/reword:

    15.9.1.8 "An implementation of ECMAScript is expected to determine the
dayl&lt;/pre&gt;</description>
    <dc:creator>Rick Waldron</dc:creator>
    <dc:date>2012-05-24T00:58:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18497">
    <title>minutes, TC39 meeting Tues 5/22/2012</title>
    <link>http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18497</link>
    <description>&lt;pre&gt;These are a combination of my edits of Rick's notes from the first topic, my notes from subsequent topics, and then my reconstruction from memory of the conversation on the last topic. So for those present, please feel free to correct the record.

Dave

----------------------------------------------------------------------

People:

BT: Bill Ticehurst, Microsoft
LH: Luke Hoban, Microsoft
BE: Brendan Eich, Mozilla
DH: Dave Herman, Mozilla
AWB: Allen Wirfs-Brock, Mozilla
AR: Alex Russell, Google
EA: Erik Arvidsson, Google
MM: Mark Miller, Google
RW: Rick Waldron, jQuery
YK: Yehuda Katz, jQuery
DC: Doug Crockford, eBay
OH: Ollie Hunt, Apple

Topic: Binary data

DH: typed arrays were designed for two use cases:
- shipping data from CPU -&amp;gt; GPU for WebGL
- doing binary file/network I/O
DH: former requires matching the endianness expected by the GPU for interpreting shader scripts (e.g. that read bytes as int32 or float64), so they designed it to use the system's native endianness
DH: latter requires explicitly spe&lt;/pre&gt;</description>
    <dc:creator>David Herman</dc:creator>
    <dc:date>2012-05-23T20:30:28</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18491">
    <title>unzip primitive and/or implicit array-of-objects toobject-of-arrays in destructuring</title>
    <link>http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18491</link>
    <description>&lt;pre&gt;While exploring use cases for data-parallel concurrency in JavaScript using the ParallelArray API (see http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism) I found myself wanting better support for multiple results from a single parallel operation. More precisely, I wanted a neat way to do array-of-objects to object-of-arrays transformations.

The same problem exists with the Array API, probably to a lesser extent as one can always fall back to explicit iterators. So, for sake of simplicity, I will use ordinary Array objects here. Consider the following simple example:

function foo (x) {
  return {odd: (x%2), twice: 2*x};
}

[1,2,3,4].map(foo);

This will produce an array of objects that have two properties: 'odd' which encodes whether the corresponding source element was odd and 'twice' that gives twice the value of the source element. What I typically want, though, are two arrays containing the odd and twice values, respectively. For instance, I might want to use 'odd' in a consecutive filte&lt;/pre&gt;</description>
    <dc:creator>Herhut, Stephan A</dc:creator>
    <dc:date>2012-05-22T21:57:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18488">
    <title>Minimal Classes as Constructors (was: Re: Classes as Cosntructors)</title>
    <link>http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18488</link>
    <description>&lt;pre&gt;

Luke Hoban wrote:

When I think of this, it looks too heavy to me.

Why use public foo = "bar"; sequence, we can use this.{...};
Why use class keyword when this does not do anything more than function 
keyword (that is, define a constructor method)?
Why put super call into extends when we have normal "super(whatever)" call?

So everything can be done as-is, with the only exception, that being the 
concise methods that are to be put into the prototype. But since it is 
the only problem, it can be solved easily: just allow concise method 
definitions in body of a constructor function (and put the in the 
prototype), and voila - you have a class:

       function SkinnedMesh(geometry, materials) extends THREE.Mesh {

         // ... note, this is the constructor body,
         // statements are allowed here

         super(geometry, materials);

         // properties on the instance object
         this.{
           identityMatrix: new THREE.Matrix4(),
           bones: [],
           boneMatrices: []
      &lt;/pre&gt;</description>
    <dc:creator>Herby Vojčík</dc:creator>
    <dc:date>2012-05-22T19:11:00</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18473">
    <title>Royalty free agreement</title>
    <link>http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18473</link>
    <description>&lt;pre&gt;Hi John,
 I think I'll need some more information in order to get the royalty free
process rolling. You said that Google is already working on that - it would
be nice to have a contact info for the representative, so I can talk to
him. Also if I need to show any documentation to people, a link to
documents would be good to have.

Regards,
  Nebojša Ćirić
_______________________________________________
es-discuss mailing list
es-discuss-4eJtQOnFJqFAfugRpC6u6w&amp;lt; at &amp;gt;public.gmane.org
https://mail.mozilla.org/listinfo/es-discuss
&lt;/pre&gt;</description>
    <dc:creator>Nebojša Ćirić</dc:creator>
    <dc:date>2012-05-22T16:28:41</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18472">
    <title>Classes as Cosntructors</title>
    <link>http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18472</link>
    <description>&lt;pre&gt;In the discussion of max/min classes at the March TC39 meeting, there was support for minimal class syntax, but a couple concerns with max/min classes in particular.

One category of concern is the (intentional) bare-bones nature of max/min.  In this case though, I think it has been demonstrated that additional concepts (class properties, privates, prototype properties, etc.) can be added to max/min later, if and when experience shows them to be needed.

The other category of concern is that max/min decides the core syntactic use of the valuable 'class' reserved keyword in the language.  Max/min chooses to use 'class' for a new kind of block with a nested constructor, instead of as direct extensions of the notion of constructor function.  

I've raised the class as constructor alternative approach before, and it's something that a few teams I've worked with inside Microsoft have advocated.  Since a choice on approach for classes will decide the foundation upon which the class keyword is used in the language &lt;/pre&gt;</description>
    <dc:creator>Luke Hoban</dc:creator>
    <dc:date>2012-05-22T14:55:59</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18467">
    <title>Meeting notes, i18n JS 5/21</title>
    <link>http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18467</link>
    <description>&lt;pre&gt;https://docs.google.com/document/d/1TYsNDU1JbNsqUxXL-123h5Hif-IikAiPidnAcw2b72o/edit

*EcmaScript i18n JS Meeting 5/21/2012

   - We need to get royalty free agreement for Ecma standard at this
   meeting or Wednesday
   - Discussion/forms on TC39 site



   - Introduction of the spec (goals, constraints)
   - Locale negotiation, collation, number formatting, date formatting
   - More was considered but we had to drop some
   - Showing examples on how to use the functionality
   - Mentioning JS buitins that use the i18n API (toLocaleString...)
   - Negotiation of having Unicode extensions and options
   - Options take precedence oved Unicode extensions
   - resolvedOptions give you what was resolved in the end
   - Implementation dependencies
      - Set of supported locales
      - Set of supported features per locale
      - Collation rules
      - Calendars and time zones
      - Various formats for numbers and dates
   - Allowing for best-fit algorithms where implementations are free to
   provide better&lt;/pre&gt;</description>
    <dc:creator>Nebojša Ćirić</dc:creator>
    <dc:date>2012-05-22T00:14:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18466">
    <title>Nightly build of Chromium with i18n API</title>
    <link>http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18466</link>
    <description>&lt;pre&gt;http://commondatastorage.googleapis.com/chromium-browser-continuous/index.html?path=Mac/138094/

Use debug console and type v8Intl to see internals...

&lt;/pre&gt;</description>
    <dc:creator>Nebojša Ćirić</dc:creator>
    <dc:date>2012-05-21T18:48:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18465">
    <title>Internationalization: Comments to 1st Edition / Draft 3 May 2012</title>
    <link>http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18465</link>
    <description>&lt;pre&gt;Comments to 1st Edition / Draft 3 May 2012

These are very similar to previous comments.

** &amp;gt;&amp;gt; p1, 3: Need update to later version of specs: Unicode, CLDR. 
Especially with requested updates to CLDR.

** &amp;gt;&amp;gt; p2, 4.3: Does not state what the cultural requirements are.  Only 
knowing the 'people involved' give me any expectation of the output.

** &amp;gt;&amp;gt; Much specification of how the API machinery operates, but not 
about the expected output.

** &amp;gt;&amp;gt; p16 11.3.2, The tailoring docs are moving to UTR#35 from UTS#10 as 
of last UTC. May be better to refer to UTR#35 for tailoring.

** &amp;gt;&amp;gt; p21-22, p25, p26: again, need more examples to evaluate this.

** &amp;gt;&amp;gt; p30, 14: Should harmonize the base localeCompare, toLocaleString, 
etc  with default locale behavior.
If a locale isn't specified, shouldn't the behavior be similar to using 
the Collator, Formatter, etc with the default locale?
&lt;/pre&gt;</description>
    <dc:creator>Steven R. Loomis</dc:creator>
    <dc:date>2012-05-21T17:37:48</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18461">
    <title>Subclassing ECMAScript arrays with Array.create(arrayPrototypeObject)</title>
    <link>http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18461</link>
    <description>&lt;pre&gt;I would like to propose a built-in method
Array.create(arrayPrototypeObject) which would create a new array
with arrayPrototypeObject as it's prototype.

Other posts already mention Array.create such as
https://mail.mozilla.org/pipermail/es-discuss/2009-December/010425.html and
a describing article
http://perfectionkills.com/how-ecmascript-5-still-does-not-allow-to-subclass-an-array/

Maybe there is a ES.next feature which allows subclassing javascript arrays
in another way then mentioned above?

Regards,

Henri
_______________________________________________
es-discuss mailing list
es-discuss-4eJtQOnFJqFAfugRpC6u6w&amp;lt; at &amp;gt;public.gmane.org
https://mail.mozilla.org/listinfo/es-discuss
&lt;/pre&gt;</description>
    <dc:creator>Henri Manson</dc:creator>
    <dc:date>2012-05-21T16:23:13</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18455">
    <title>WeakMaps functionality, within regular object semantics</title>
    <link>http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18455</link>
    <description>&lt;pre&gt;From a user perspective, I'm really happy to see WeakMaps in the
proposals.  The syntax for it deviates from js' currently cohesive core
object model, though; requiring getter and setter methods and having no
literal format.

One alternative that may work neatly is a 'hold me weakly' operator.  For
example's sake, I'm going to use *, but there may be other eligible ones:

*As a key*:

var key = {}
  , obj = { *key: 'val' } // when `key` is eligible for GC, the key:value
pair gets deleted

obj[key] // -&amp;gt; 'val'; retrieval by `key` doesn't require the operator


*As a value*:

var val = {}
  , obj = { key: *val }  // likewise, when `val` is eligible for GC, the
key:value pair gets deleted



*As both a key and a value*:

var val = {}
  , key = {}
  , obj = { *key: *val } // when *either* `key` or `val` is eligible for
GC, the key:value pair gets deleted


*Non-literal form*

var key = {}
  , val = {}
  , obj = {}

obj[*key] = *val        // behaves the same as obj = { *key: *val }


I'm almost 100% convinced th&lt;/pre&gt;</description>
    <dc:creator>Hugh Jackson</dc:creator>
    <dc:date>2012-05-21T14:24:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18453">
    <title>ECMA-262 purview? was re: FFT module</title>
    <link>http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18453</link>
    <description>&lt;pre&gt;This thread brings up an interesting question:
Once we have modules, should we have a place other than ECMA-262 to define
standard host-environment libraries that ship with browsers?

On 21 May 2012 04:54, Jussi Kalliokoski &amp;lt;jussi.kalliokoski-Re5JQEeQqe8AvxtiuMwx3w&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:



&lt;/pre&gt;</description>
    <dc:creator>Wes Garland</dc:creator>
    <dc:date>2012-05-21T11:19:48</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18452">
    <title>ToNumber("0b1001")</title>
    <link>http://comments.gmane.org/gmane.comp.lang.javascript.ecmascript4.general/18452</link>
    <description>&lt;pre&gt;I was going over the latest draft and noticed that, while binary and octal literals have been introduced in 7.8.3, they weren’t added to 9.1.3.1 (“ToNumber applied to the String type”). Should they be?

Pros: symmetry. Cons: breaks backward compatibility (currently ToNumber("0b1001") returns NaN).
_______________________________________________
es-discuss mailing list
es-discuss-4eJtQOnFJqFAfugRpC6u6w&amp;lt; at &amp;gt;public.gmane.org
https://mail.mozilla.org/listinfo/es-discuss
&lt;/pre&gt;</description>
    <dc:creator>Domenic Denicola</dc:creator>
    <dc:date>2012-05-21T08:55:41</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.lang.javascript.ecmascript4.general">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.lang.javascript.ecmascript4.general</link>
  </textinput>
</rdf:RDF>

