gmane.comp.lang.javascript.ecmascript4.general

Array.prototype.search

Rich Walrath — 2012-05-26T04:26:13

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 < len; i++ ) {
if( i in this && 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 > c.x;
});

The end result would be the { x: 163, y: 40 } object because it has the
largest x value, which is what we were looking for.



--------------------------
Rich Walrath
_______________________________________________
es-discuss mailing list
es-discuss-4eJtQOnFJqFAfugRpC6u6w< at >public.gmane.org
https://mail.mozilla.org/listinfo/es-discuss

Arity checking?

Axel Rauschmayer — 2012-05-25T07:21:26

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.

Array.prototype.take

Irakli Gozalishvili — 2012-05-25T00:42:43

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< at >public.gmane.org
https://mail.mozilla.org/listinfo/es-discuss

Generators improvement idea

Irakli Gozalishvili — 2012-05-25T00:29:28

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/

_______________________________________________
es-discuss mailing list
es-discuss-4eJtQOnFJqFAfugRpC6u6w< at >public.gmane.org
https://mail.mozilla.org/listinfo/es-discuss

"strict mode" |with| proposal

Aymeric Vitte — 2012-05-24T21:22:39

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 some rules (must be in root, can not be 
invoked twice, etc), might look strange but it's a kind of LHS lexical 
|this|, so maybe no more disruptive than the lexical this

At the end the result is simple and simple to use, does eliminate a lot 
of complications, is flexible (you can decide whether |with| stuff 
reminds isolated or not and vice-versa, clone global var or not, freeze 
stuff or not, etc), and probably light in terms of specs 
modifications/implementation.

const classes for max/min

Russell Leggett — 2012-05-24T19:07:07

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<http://wiki.ecmascript.org/doku.php?id=harmony:classes#const>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
    const pHealth = Name.create();

    // adding const here triggers a few key things
    // 1. The variable Monster will be const
    // 2. Monster.prototype is frozen
    const class Monster {
        // 3. the constructor will be frozen (which includes adding
"static" style functions)
        constructor(name, health) {
            // 4. anything added to the instance here will be
writable/non-configurable
            this.name = name;
            // using private names allows protection against mutation from
the outside
            this[pHealth] = health;
            5. before returning, instance is frozen - see original const
class for details
        }
        // 6. all other methods on the prototype will also be frozen
        attack(target) {
            log('The monster attacks ' + target);
        }

        // get/set (also frozen) can be used to enforce encapsulation on
data members
        set health(value) {
            if (value < 0) {
              throw new Error('Health must be non-negative.')
            }
            this[pHealth] = value
        }
        get isAlive() {
            return this[pHealth] > 0;
        }
    }

    // cannot reassign
    Monster = foo; // error, Monster is const

    // cannot modify constructor function
    Monster.myStaticFunc = function(){}; // error, constructor is frozen

    // cannot modify the prototype
    Monster.prototype.bar = bar; // error, prototype is frozen

    let m = new Monster("Beholder",45);
    m.name = "Fred"
    log(m.name); // logs "Fred"


    // only has a setter
    log(m.health); // error, no getter
    m.health = 0;
    log(m.isAlive); // logs false

    m.randomProp = foo; // error, instance is frozen

The only major difference between what I am proposing now, and the original
const class, is that I stick with just using `this.name = name;` instead of
`public getName(){ return name;}` ( I think `public name = name;` would
have been allowed, and almost exactly what I'm intending instead of adding
a method). Additionally, of course, my proposal is based on max/min instead
of harmony classes, so the other features are obviously not allowed.

The only big hole I'm noticing is that const classes basically could not
have static members. It is future friendly to addition of the static
keyword, though if we wanted to add that.

Here's a max/min const class version of the const class example from
harmony classes:

    const pX = Name.create();
    const pY = Name.create();
    const class Point{
        constructor(x,y){
            this[pX] = x;
            this[pY] = y;
        }
        get x(){ return this[pX]; }
        get y(){ return this[pY]; }
    }

I think this could really work, because it is minimal impact, and does not
affect future friendliness. Other additions like private properties and
static methods, for example, would easily fit before ES6 is finalized or as
a future. enhancement.

- Russ
_______________________________________________
es-discuss mailing list
es-discuss-4eJtQOnFJqFAfugRpC6u6w< at >public.gmane.org
https://mail.mozilla.org/listinfo/es-discuss

announcing normative ECMAScript specification in HTML

Allen Wirfs-Brock — 2012-05-24T17:58:16

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< at >public.gmane.org
https://mail.mozilla.org/listinfo/es-discuss

Clarification of [[Prototype]] of Intl.Collator.prototype

Yusuke Suzuki — 2012-05-24T12:49:26

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.toString;  // this is not defined in Intl.Collator.prototype


never stops because of infinite loop of [[Prototype]] resolution in
[[GetProperty]].
intl402/ch12/12.3/12.3.js and intl402/ch13/13.3/13.3.js have the same bug.
This is reported in
https://mail.mozilla.org/pipermail/test262-discuss/2012-April/000098.html
And later I'll file issue to bugs.ecmascript.org.

So, to make it clear, I suggest adding description about [[Prototype]] of
Intl.Collator.protoype like ES5 Array.prototype in section 15.4.4, like

The value of the [[Prototype]] internal property of the Intl.Collator


Regards,
Yusuke Suzuki
_______________________________________________
es-discuss mailing list
es-discuss-4eJtQOnFJqFAfugRpC6u6w< at >public.gmane.org
https://mail.mozilla.org/listinfo/es-discuss

TC39 meeting Wed 5/23/2012

Rick Waldron — 2012-05-24T00:58:55

# 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
daylight saving time algorithm."

AWB:
- There needs to be a specification of some sort, as other aspects of the
standard rely on this.

more discussion.

Some locales do change

LH:
- Operating systems and browser do have disagreements

AWB:
- Either NL or LH can draft replacement text for
15.9.1.6 and 15.9.1.8

more discussion.

Resolution: Remove the spec text, new additions will be considered as new
proposal

Not errata.

# 4.10 Object.observe (Rafeal Weinstein)

Rafeal Weinstein:
- Introduction to proposal

See: http://wiki.ecmascript.org/doku.php?id=strawman:observe

MM:
- In favor of spec'ing an event loop

Alex Russel:
- This doesn't actually change anything in the spec today

MM:
- Run program code to completion, etc.

LH:
- last execution context

AWB:
- Currently no concept of "last execution context"

YK:
- It's implicit

LH:
- Agrees, needs to be specified

OH:
- What happens if the object is mutated before the callback delivers?

Explanation of side-channel communication of objects.

YK:
- Explains the idea, needs of observing an entire object.

Discussion about object safety.

Discussion about frozen object safety.

Discussion about non-configurable, non-writable property change delivery.

MM:
- Will adding the text "Any non-frozen" change the operational behaviour?

YK:
- No, frozen objects should probably not deliver a property changes

Erik Arvidsson:
- Deferring to MM

MM:
- Observe proxy?

EA:
- Non-issue, the traps only the final property

LH:
- More explanation of Proxy property trap behaviour

AWB:
- There is too much going on at low level with this proposal

Discussion about importance

BE:
- Important does not mean "it's in"

RWeinstein:
- What if this didn't apply to Proxy?

BE:
- The DOM…

More discussion regarding security, naivety of proposal

BE:
- Let's have Tom Van-Cutsem take a look at this and iron out

RWeinstein:
- Asking for blessing to prototype in v8: approved.

Resolution: Needs more exploration

# Spec Issues (Allen Wirfs-Brock)

Object.isObject

Misses the mark on actual needs.

BE:
- Possibly, Object.typeOf()?

Doug Crockford:
- Need to re-address this for reality.

YK:
- Will write strawman for review at next meeting.

Resolution: Consensus to remove from draft

super

LH:
- This may be too confusing for the common user

AWB:
- Asserts that super is defined correctly for classes
(explanation)

Should super be allowed in all function forms or restricted to classes?

Resolution: Defer super outside of classes

Concise Methods

Resolution: In favor

Concise Body

Resolution: Only for ArrowFunction

Property Assignment Shorthand

eg.
function point(x, y) {
return { x, y };
}

{ x: x, y: y }

This is too unclear
w/r to destructuring: both, or nothing.
Plenty of opposition based on clarity.

Resolution: Nothing, no change.

Triangle

Is capable of giving up private names

If people have __proto__ they will not use <|.

MM:
- From a security perspective, I'd like to move __proto__ out of annex B
and into normative body

BE:
- If MS puts __proto__ in IE, then it becomes defacto standard and we might
as well put it in the standard.

1. __proto__
2. grawlix

Resolution: Indefinite postpone

Moustache

o.{ p: v }

BE:
- Propose that moustache is kept, but still consider Object.extend

MM:
- Would like to consider both moustache and Object.extend

How about… both?
= assign
: define

ie.

o.{
p1: "to define",
p2 = "to assign"
};

Positions:

Just Define
Just Assign
Both Define and Assign
Alone
Applied to object literals

Resolution: Return to strawman for revision, needs own wiki page.

Computed Keys

Erik Arvidsson:
- Today, properties are static and knowable, computed keys are not knowable.

Resolution: Deferred.

SealedObjectLiteral

See: https://bugs.ecmascript.org/show_bug.cgi?id=362

Resolution: Postponed until ES7.

String.prototype.toArray

Resolution: Removal from draft.

# Weak Refs

Yehuda Katz:
- Use case: observers

Resolution: Continued, due to lack of time.

# Value Objects

Brendan demos, explanation of the implementation and operator overloading
_______________________________________________
es-discuss mailing list
es-discuss-4eJtQOnFJqFAfugRpC6u6w< at >public.gmane.org
https://mail.mozilla.org/listinfo/es-discuss

minutes, TC39 meeting Tues 5/22/2012

David Herman — 2012-05-23T20:30:28

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 -> 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 specifying endianness, which DataView API allows
DH: but casting ArrayBuffers to different types exposes system endianness, and basically the entire web is implemented on little endian systems, so the web is being written with the assumption of little endian, despite not being specified
DH: we should specify little endian. bi-endian systems (which many modern little-endian systems actually are) have HW support for little-endian; but big-endian systems can implement byte swapping by compiling shaders to do the byte swapping themselves
YK: I agree; hard for devs to reason about endianness. expecting large use cases for binary data?
DH: yes; e.g. crypto algorithms, optimizing bignum libraries; I wrote a "float explorer" that displays bit patterns of IEEE754 doubles by casting, and discovered after months that my explicit check for system little-endianness was flawed and always produced true, but I couldn't test so I only discovered the flaw by chance.
AWB: agree that most devs will not understand endianness differences
LH: do expect some big-endian UA's
DH: right, in particular game consoles; some have hardware support for bi-endian; how robust that support is is unknown. but can still implement byte-swapping by compiling shaders.
DH: right now, there's no one implementing big-endian browsers making the case that they can't implement little-endian, and meanwhile the web is being written to assume little-endian.
YK: if we standardize little-endian, does it become impossible to discover the system's endianness?
DH: yes, but we could add a feature-detection API that explicitly provides that information. you wouldn't need it though.
DH: if real perf issues arise, willing to consider little-endian by default with explicit opt-in to big-endian. still possible to write unportable code (e.g. blind copy-paste programming), but at least less likely. but let's not solve the problem till we know we have it
AWB: endianness is clear for integers, but what about floats? aren't there other variations e.g. what order the mantissa and exponent and sign go in?
DH: not sure, but we should just standardize whatever format the web is using.
AWB: yes. if you know you need big endian, you'll do the conversion
DH: mostly that's probably just for I/O, where DataView does that for you automatically
DH: standardize little endian?
EA, YK: de facto standard.
LH: I need to contact people on my end; there may become big-endian browsers
DH: broadly speaking, little-endian has won in the hardware world. regardless, this is becoming the de facto standard. HW support will likely get better and better, and leaving it unspecified is solving a problem that doesn't exist, while creating issues of its own.
BT, BE: DataView defaults to big-endian
DH: yes, people are unhappy about that inconsistency. we could change DataView to default to little-endian for consistency. but in the world, big-endian has won as the network byte order, while little-endian has won as the CPU byte order.
BE: a foolish consistency!
DH: right-- the defaults are modelled on reality, and reality is lumpy
BE: yes. <<provides some historical insight>>
YK: what observable effects would this change have on WebGL?
DH: likely none. AFAIK when you create data for WebGL, you don't use casting in ways that care about endianness, you just ship to the GPU, and that's what's sensitive to the endianness
YK: could we eliminate the observable effects by just converting all the data en masse?
DH: no, not that simple; you have to know which bytes need to be swapped
DC: I thought we were going to replace typed arrays. can we just leave it out?
BE: they'll go to W3C. this is reality; we must embrace
DH: we can embrace and then create better, more ergonomic extensions
DC: tell me more
DH: typed arrays are views over ArrayBuffers, which are buckets of bytes; we add a new view type of structs:

    S = struct({
        x: uint8,
        y: uint8
    });

S is not a struct object but a struct type. then:

    x = new S

creates a new instance of this struct type

    A = Array( S )

again, a type, not an instance

YK: that's a little confusing
DH: whole idea is an API for creating new types, so there's a meta-level here that is inherent complexity; can certainly bikeshed API names later
LH: idea we discussed before was making the .buffer null of a struct unless you explicitly constructed it wrapping an existing buffer
DH: yes, and once we do that, we can add pointer types:

S = struct({
    x: uint32,
    foo: object
})

DH: for security, *absolutely cannot* expose the buffer to casting
DH: also, enforce alignment constraints to maintain invariant that normal ArrayBufferViews never have unaligned access; will write this up and could use help checking my logic
AWB: isn't there an inconsistency about when there's padding and when there isn't?
DH: no, if you create an unaligned struct type:

S = struct({
    x: uint8,
    y: uint32
})

then if you construct it fresh, you can't observe the padding, and if you wrap it around a buffer, you get an error:

o = new S; // can't access buffer
O = new S(buf, 2) // error: unaligned type

DH: as always, you can do unaligned access via data view:

d = new DataView(buf, o)

v = d.get(S, 17) // unaligned read

DH: in that example, v is an object pointing to index 17 in buf, and property accesses do the proper logic to perform unaligned access
LH: since strings are pointers, would also be good to be able to have a string type
BE: Waldemar wanted that a while back
DH: I think he was talking about inline strings, which is best treated as a byte array and use Josh Bell's encoding/decoding API (in progress); but I agree we should make it possible to have all JS values; string type is a no-brainer, +1
<<everyone generally favorable>>


Topic: Classes

LH: anything we standardize finalizes basic choice of syntax; maxmin decides we're going to have a new kind of body instead of trying to make class be a constructor-like concept
AWB: we need to agree on something, so let's agree on this basic structure
MM: constructor syntax is DOA for good reason, b/c of the scope issues; in my proposal, class parameters *were* in scope but methods were instance methods; but this was a non-starter for implementation
LH: I think there are ways to mitigate: put constructor locals in scope but poison them
RW: that's too confusing
BE: howling, screaming wart
MM: what's the advantage over maxmin?
LH: syntactic weight is fairly significant
AR: there's weight, but it's a syntactic entryway to more features
LH: blocked off one key door, which is the constructor syntax which is the shortest and simplest of all possibilities
MM: one of the big advantages of JS is simple lexical scope; confusion of poisoned names is more important cognitively and the shorter syntax doesn't compensate
DH: what's the syntactic convenience?
LH: one less level of indentation
YK: at cost of clarity
RW: and you added public!
BE: which cost is worst, public keyword or not having the thing you're calling new on be hoisted to the top?
DH: public keyword is almost outright hostile to programmers; goes completely against the rest of the way JS works
YK: given that maxmin is so minimal, I would like some escape valves for making it something we can build on (extension hooks)
AWB: we need consensus on base level first, before we go into extensions to the proposal
AWB: could you live with maxmin alone?
YK: no. I will receive pressure to use class syntax for my existing class systems, but without at least one escape valve, I will have to choose between saying no or saying yes and killing features
AR: there'll be needs for things like mixins
EA: that's been debunked; RHS is an AssignmentExpressions; mixins are perfectly possible
AR: but there will be various things that can't be done
AWB: you can do this with a function that implements your hook
YK: that asks my users to call a special function
MM: there's simply no proposal for this additional feature for us to evaluate
AR: will you attempt to stone maxmin before they get out the gate before we can agree?
YK: well, no
LH: I won't try to stone classes, but I really hope if we're going to put something in the spec, a) it can actually be used in most cases where most people want to use it, and b) it be forwards-compatible with addressing remaining places
AWB: I wouldn't be behind this if I didn't think both those things are true
YK: I think those things are true; I am personally concerned that I will receive requests for things I can't implement
AWB: I think people will have issues in the short-term but they'll eventually improve
DH: rollout and adoption are important; YK, I'd like to know more specifically what you can do now that you can't do with maxmin
RW: try/catch never would've happened if people said "I can't use this now"; in 3 years, I think you'll rebuild Ember with classes
YK: here's why I know it's a real issue: people want Ember classes to work with CoffeeScript classes, and I have these exact issues
AR: no one's suggesting that it's impossible to do more than maxmin -- even in ES6 time frame -- but we need to agree on base foundation
DH: I think Luke's Ocaml syntax is too confusing, it doesn't win enough for convenience, and it's less mainstream
BE: Ocaml! I knew it!
LH: this clearly has limited amounts of support
AR: we've been through this part of the design process and sympathize, but we've already come to conclusion it doesn't work
MM: keeping scope simple is the most important thing IMO
LH: but what I miss is the instance properties, the ability to see shape of the object is very valuable, e.g. for completion lists in tools
AWB: if you have maxmin as starting point, there are ways to address it
LH: the proposed extensions I've seen are awkward
AR: this has been solved in other languages e.g. C++ initialization list
LH: I won't stand in the way
DH: pulse?
LH: I think Waldemar was totally opposed, I'm not totally opposed, just had concerns
DC: my concern: this isn't new capability; but if it doesn't address all the needs, it'll just add more confusion and won't help
AWB: there's significant debate on a lot of things that could make things easier, but there's a basic structuring that is useful: it's useful not to have to wire up the prototypes properly
DC: but a lot of people are doing this with libraries
AR: but then they're not interoperable
DC: I don't feel compelled to go forward with something we can't be sure isn't right
YK: I see this being on the way to that, but not there yet
BE: you want something, Waldemar wants something else...
YK: I think it's ok if it's a subset, but we should be clear about that, so I can hold the line against using it
DC: tactically I'm opposed to that; if we're on the way but not there, let's do nothing
AR: I was in your camp some time ago. so much complexity to build a proposal that hangs well together that you will have to throw some use cases overboard. we have a long history of not doing classes on the basis that we should wait to do it right. but we also have a long history of iterating on and improving on things that are already in the language. I have faith that we will work to iterate
DC: I'm saying we shouldn't ship until we're sure we're right
DH: design does not have empirical or rationalistic methods of validation. all you can do is discuss, prototype, build examples, and try it out, all of which are part of the Harmony process
DC: I'm fine with consensus
BE: Waldemar wants the ability to have "final" or "sealed" objects that can have errors when mis-named properties, which Mark would like as well
AR: I thought Waldemar wanted *only* that
MM: I think this is a subset of the original class proposal from last spring that Waldemar was on board with; the restrictions were only on const classes
BE: other than future-hostility concerns, which aren't falsifiable
MM: can check whether this is forward-compatible with the May proposal
AWB: that wasn't sound, it was just a whiteboard sketch
BE: Mark's saying that we can grow in the direction of the things Waldemar wants
AWB: I specifically asked Waldemar to say specifically what he thought this was interfering with, but he hasn't come back with anything; don't see why that couldn't be added with more syntax
AR: ISTM there's a fight over defaults
DH: if const is default, we will all be burned at the stake
AR: can't we get something useful if we don't solve the const problem?
BE: it's not clear to me people are asking for what Waldemar is asking for
MM: let's not spend time guessing Waldemar's position
BE: sure, let's just separate the default question from const question; can we agree const should not be default?
MM: I think that was always the agreement since last May
BE: I think when Waldemar returns, we may have to find a way to get past const, to achieve consensus
AWB: I think we should move forward, start specifying maxmin, knowing that we can remove it later
YK: I would like to make a stake in the ground
MM: until Waldemar can make his case, this isn't consensus
AR: there's some room here to suggest we can't wait forever
EA: can we start saying let's build on this instead of waiting another two months?
MM: let's not push until Waldemar has returned
AR: OK, but we do have a deadline, and there's been plenty of time to register complains
EA: I would just like to start prototyping
AWB: and I would like to start doing spec work
MM: sure, we should all push on all fronts, but we don't have consensus without Waldemar's agreement
BE: correct


Topic: __proto__

OH: it's a getter/setter in JSC
MM: one sane approach: refuses to change prototype of object born in another global; other sane approach: refuses to modify prototype of any object that inherits from that context's Object.prototype
DH: what about the getter?
MM: always works; equivalent to Object.getPrototypeOf
AWB: exposing the setter as a function means that any method call with one argument could potentially be a proto modifier
DH: can't you already do that with a function that delegates to .__proto__ ?
AWB: if you thought you deleted Object.prototype.__proto__ but someone squirreled away a copy of the setter
BE: I just don't like it
MM: not fatal for security
BE: we're inventing something new that's not been tested on some pure aesthetic of not wanting magic data properties. I just don't like it
DH: when we already do that with array.length and indexed properties anyway!
BE: this is a turd we do not want to polish
MM: I don't like the way it's specified
DH: sure. I think we agree about the behavior
BE: agreement: it's in Annex B, it'll be a pseudo-data property
MM: I don't think that's clear
EA: I would pick an accessor
BE: this isn't a clean-slate design experiment!
MM: b/c Firefox doesn't implement the accessor?
BE: b/c no one other than JSC very recently
MM: we can analyze the security properties
BE: this is not about security, it's about unintended consequences
YK: is there an advantage to making it an accessor?
MM: yes: the actual action is that it has a magic side effect
BE: that's an aesthetic preference
OH: the pre-accessor behavior of JSC was that every object instance had the magic property; from our point of view, being able to extract the accessor is in no way different from what you could already do
BE: acid test: `o.__proto__ = null` -- what happens?
OH: in old JSC, it remained magic
DH: comes down to distaste of another magic data property vs distaste of a portable, well-specified proto-updater function
YK: people will use it
BE: and maybe someone will come up with some zero day, I can't predict that
DH: it's strictly more risk for sake of a purely aesthetic reason, in an already aesthetically nasty space
BE: yes, should be a risk analysis, not an aesthetic analysis
YK: I agree
MM: I would like a more modular specification than poisoning the semantics of [[Get]] etc; but think of how expensive the magic of array length has been
BE: this is already shipping in a bunch of browsers, and in some of them it's already a magic property; the developer-facing cognitive load is a wash; developers just want it to work, they don't care whether it's an accessor
DH: I can predict the security bugs: the implementor just thinks about the normal case, but the attacker takes the accessor out, installs it on an object that inherits from a proxy to an object from another global etc. etc. and something internal breaks
MM: that's the most compelling argument I've heard. the additional testing surface area is much bigger
DH: Arv?
EA: I'm not gonna block this
OH: I think it would be nice to have a mechanism that let you specify getters/setters that weren't extractable
DH: actually proxies basically *are* such a mechanism
AWB: I don't like getters/setters that can't be reflected


Topic: Spec terminology

AWB: confusion about "host object"; I'd like to eliminate concept of "host object" entirely, introduce new terminology
- object: runtime entity w/ unique identity and exposes properties
- mundane object: object that uses default behaviors for chapter 8 internal methods
- exotic object: object that provides non-default behavior for at least one of the internal methods
DH: I would say that "plain" is better than "mundane"; also value objects, were they to succeed in Harmony, don't have identity
AWB: we can cross that bridge when we come to it
DH: anyway I like this; makes clearer where the extension points of the language are
AWB: note that proxies are exotic
MM: are array instances exotic?
AWB: yes
DH: is that a problem?
MM: no, just surprised me
AWB: I'd like functions and other "normal" things to be classified as mundane
DH: but arrays should still be exotic?
AWB: yes
DC: Ecma members can be "ordinary"
AWB: ok, "ordinary" and "exotic"
AWB: another dimension of classification?
- standard object: defined by ES specification
- built-in object: provided by ES implementation but not defined in ES specification
- platform object: provided by host environment
<<mass confusion>>
AWB: I agree these distinctions are unclear
DH: I think the first dimension was great! it moves us in the direction of not *needing* the second dimension
AWB: I agree, and I will see if it's possible to eliminate the second dimension
AWB: now, a dimension for functions:
- function: an object that exposes the [[Call]] internal method
- ECMAScript function: function whose invocation result & side effects are provided by evaluating ECMAScript code
- alien function: function whose invocation result & side effects are provided in some manner other than by evaluating ECMAScript code
- standard function: function whose invocation result and side effects are defined by the ECMAScript specification (mostly ch 15)
DH: why do we need this? job of implementation is to make it indistinguishable that a function is alien
AWB: setting up initial environment has to keep track of variable environment etc
BT: it's unobservable
DH: you can't tell!
LH: are you saying there's a flaw in the current ES5 spec?
AWB: when you activate a chapter 15 function, you don't go through any of the normal process
MM: Function.prototype.toString has requirements on functions that *must* be ECMAScript functions; so there's a distinction between "must-be" and "may-not-be"
AWB: but Chapter 15 functions need access to the current global's intrinsics (e.g. for "initial meaning of new Array" etc)
BE: you can get to that via [[Scope]]
DH: I would rather eliminate the alien function distinction, and the steps in Chapter 15 can be implemented in pure ES
AWB: I'll just have go through and see how many distinctions I can eliminate
MM: what are the "intrinsics"?
DH: things like where the spec says "as if via `new Array` for the initial value of Array"; loaders rationalize this, and each loader has its own set of intrinsics
YK: "realm" is used in basic auth
DH: "realm" is a little thesaurus-y; I like "context" but "ExecutionContext" used in ES already, so "global context"
AWB: "context" doesn't feel big enough
MM: so [[Scope]] gets you to the context?
AWB: you can share global objects between loaders!
DH: oh right, so [[Scope]] is not it -- needs its own [[Context]]
AWB: top-level environment record gets you to it
BE: don't have two independent fields that are required to agree
DH: yeah, as long as we can get to the global context via the top-lex environment record, we should just get to it via that
DH: popping the stack, I like "global context"
YK: I like "global context"
BE: "context" is almost meaningless
MM: "shire"... lulz
AWB: "island"?
DH: <<winces uncomfortably>>
DH: "home"?
AWB: not bad... already using for something else but I could rename it


Topic: do-expressions

DH: allows you to evaluate expressions with control flow or temporary variables:

a = do {
    let tmp = f();
    tmp * tmp + 1
};

workaround:

let tmp; // scope pollution!
a = (tmp = f(), tmp * tmp + 1);

workaround:

a = (function() {
    var tmp = f();
    return tmp * tmp + 1;
})()

YK: CoffeeScript gives you the latter
DH: the IIFE doesn't "say what you mean" -- boo boilerplate
YK: also, TCP hazards
MM: strongest argument in favor is for code generators
DH: well, I think the developer convenience is an even stronger argument
EA: I want this most for code generators
MM: strongest or not, it's still compelling for code generators
DH: arguments against that I've heard:
- eliminates the current structure of JS syntax where statements are always at outermost level of a function body
- exposes the completion value of statements, which is only otherwise observable via eval
YK: it's pretty clear what the result is
DC: the "do" syntax will be confusing to those familiar with do-while
YK: you can think of it as do-while-false
DH: I think it reads really naturally as English: "do this" means do it once, "do this while blah" means do it some number of times
DH: pulse of the room?
<<mostly favorable>>
LH: my standard concern: the overall cost of so much new syntax; I would certainly use this, and I like it, but all these conveniences add up in cost
DC: I don't think we ever consider the overall design
DH: sick of that accusation; we constantly consider the overall design
BE: there is an important point about the cost of syntax, and we need to take account of all of the syntax we've proposed
AWB: worth making everyone come up with a priority list?
BE: that's a little "fighty", but we will need to take stock and make some cuts at some point
DH: I imagine I'd cut do-expressions before anything else
EA: I want them more than comprehensions
DH: yeah, I've championed comprehensions for so long I hadn't really reconsidered; I love them but I could see how you might prioritize do-expressions
DH: I want to make a couple points about the big picture:
- there is a meme that TC39 doesn't understand complexity budgets and is out of control
- please do not spread this meme; it's false
- one thing the recent controversy, including JSFixed, has shown me is that TC39 needs to improve our communication
- there's a lot of misinformation, and a lot of unhappy people, when they start talking with us, end up finding out they're actually pretty happy with the direction ES6 is going in
- I will be redoing the entire wiki to focus on community first, committee second, and to make the big picture clearer
- but we all could think about ways to increase our communication with the community
AWB: in some ways the anger is actually a consequence of being open
DH: yes, but we can still improve our communication
BE: we still need to think about whether and what we should scale back
AR: people are resistent to change; once features land they'll use them
DH: tension between needing to grow a language incrementally but about the standards process taking many years between revisions; either underserve users by simply not growing enough, or freak them out by landing many things at once
YK: roll-out of individual features in browsers can help, even preffed off
DH: just want to say that we *do* consider complexity budget, we *have* cut a ton of things, and the ES6 feature set has really strong coherence
AR: go team!

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

unzip primitive and/or implicit array-of-objects toobject-of-arrays in destructuring

Herhut, Stephan A — 2012-05-22T21:57:11

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 filter operation on 'twice'. One way to achieve this is to write a little unzip helper:

Array.unzip = function unzip(a) {
  var r = {};
  for (var e in a) {
    for (var k in a[e]) {
      (r[k] || (r[k]=[]))[e] = a[e][k];
    }
  }
  return r;
}

which then allows me to conveniently specify the array-of-objects to object-of-arrays conversion like so:

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

Throw in destructuring as per http://wiki.ecmascript.org/doku.php?id=harmony:destructuring, and you get a pretty workable

{odd, twice} = [1,2,3,4].map(foo).unzip();

Ideally, when implementing this, map should already materialize its result as two separate arrays if its result is only used by an application of unzip. A built in unzip with fixed, well known semantics would make this feasible without the need to analyze what a potential user defined unzip does. 

Improving on this some more, one could also extend destructuring to include the required array-of-objects to object-of-arrays transformation and thus directly allow the programmer to write

{odd, twice} = [1,2,3,4].map(foo);

The new semantics of destructuring would have an additional case that, whenever the rhs is an array like value but the lhs is an object pattern, the rhs is first transformed into an object of arrays before the pattern is applied. An implementation is of course free to perform the two steps at once, allowing for optimizations in cases where only parts of the elements are selected, as in

{odd} = [1,2,3,4].map(foo);

Extending destructuring this way does not impact other cases of destructuring. Consider the case where the programmer expected an object but got an array of values. The expression

{odd, twice} = [1,2,3,4];

would still yield odd and twice as undefined. If the lhs is an array pattern, the extended semantics do not apply at all.

To summarize, I propose two things. Either, rather conservatively, that an unzip primitive be added to Array/ParallelArray or that destructuring be extended such that if it encounters a lhs object pattern and a rhs evaluating to an array of objects that it be destructured into objects of arrays corresponding to variables specified in the lhs.

Stephan

Minimal Classes as Constructors (was: Re: Classes as Cosntructors)

Herby Vojčík — 2012-05-22T19:11:00


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: []
         };

         // methods on the prototype object
         update(camera) {
           // ...
           super.update();
         }
       }

If the parsing is the problem and [NoNewLineHere] is not an option, then 
it may be possible to use "public" or even "class" ;-) keyword to prefix 
such concise methods.

So, what would those "few teams [...] inside Microsoft" say to this?

Herby

P.S.: Yes, there is no extends for functions, but I keep saying there 
should be one. For the moment, it can be supplemented with <| but only 
for function expressions.

Royalty free agreement

Nebojša Ćirić — 2012-05-22T16:28:41

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< at >public.gmane.org
https://mail.mozilla.org/listinfo/es-discuss

Classes as Cosntructors

Luke Hoban — 2012-05-22T14:55:59

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 going forward, I did a writeup of the alternative syntactic approach at http://wiki.ecmascript.org/doku.php?id=strawman:minimal_classes_as_constructors for comparison.  

Here's one of the examples from the write-up:

    class SkinnedMesh(geometry, materials) extends THREE.Mesh(geometry, materials) {
      
      // properties on the instance object
      public identityMatrix = new THREE.Matrix4();
      public bones = [];
      public boneMatrices = [];
    
      // ... note, this is the constructor body, statements are allowed here
    
      // methods on the prototype object
      public update(camera) {
        // ...
        super.update();
      }
    }

Classes as constructors aims to align more closely with existing 'function' syntax, augmenting with the ability to declaratively specify members of the class.  Importantly though, methods (and accessors) defined in the class body are bound as prototype properties, not instance properties.  This can lead to more succinct classes in many cases, and keeps the notion that a class is primarily a constructor function.

Luke

Meeting notes, i18n JS 5/21

Nebojša Ćirić — 2012-05-22T00:14:45

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 than default algorithms
   - Extensions to the spec are allowed if prefixed by vendor tag
   - Testing is hard because of variations in the data and implementations
   - Discussion about default behaviours
      - Single data source?
      - More examples in the spec to make developers life easier
      - Allan - 262 doesn’t specify everyting so there is a precedent
      - jQuery - example of navigator.language across browsers not being
      the same (en, en-US, en-us)
      - Ritchard - should we focus on each area and see if we can tighten up
   - Locale lookup
      - Explanation about de-DE vs. de
      - Even simple lookup algo. won’t give the same results
      - Determinism is an issue en->en-US or en->GB
   - Collator
   - NumberFormat
   - DateTimeFormat
   - Loomis: Make it clear in the spec (14.3.1,2,3) that the respecified
   functions behave as if the constructors were called with blank locale list
   and options (old behaviour is gone).
   - Loomis: Add references to third-party implementations to use CLDR or
   UCA if don’t have other options.
   - Covered spec. update (collation keys removed, using internal Object
   type)
   - Implementations
      - Add v8toLocaleString to v8?
      - Remove v8 prefix from the implementation because there is no
      competing proposal
      - Put it behind a flag?
      - Microsoft is continuing in the labs, updated to the current spec,
      couple of known limitations, but minor. They are shiming toLocaleString.
      TBD for when is it going to be in the browser. No vendor prefix.
   - Test suite
      - Microsoft medium to long term would add tests
      - Google added 35 tests
   - Community feedback
      - Passing around locale list - default is a problem - where to put it
      as a global - spec doesn’t say that default locale can’t change
      - Pattern string for date format - postponed for version 2.0
   - Allen: should there be a global default at all?
   - Intl taking locale list as a parameter? That list would become
   default. But constructors are not frequent in the code, format(), compare()
   are. And in toLocaleString() is a convenience method, so we don’t worry
   much. No need to change the spec.
   - ErikMS: List of default locales. Long discussion about merging lists,
   what if each service picks different locales? What if locales are not
   supported at all? 10.1. could be changed to say it could have 1+ instead of
   1 iteam? Should new LocaleList() return empty list? A defaultLocale()
   method/static that returns system default list?
   - Skeleton string for dates
      - Skeleton property maybe? (LDML) - v2.0 with agreement
      - Style property (short, long, medium)? - v2.0 with agreement
   - Pattern for dates maybe don’t have place in the Intl?
   - Moment.js for date formatting (lang files) - http://momentjs.com/
   - Date formatting - take a look at the other libraries
   - Move numbering system information wrt BCP47/ (move from
   supplemental/)? Clarify the status within LDML spec. Leave couple rows in
   the table, and point to LDML spec.
   - Collator variant name change? Probably good enough.
   - List of default locales? Why not have LocaleList() return a list from
   user preferences?
   - Async issue - not an issue since we have at most 9MB of data total,
   which is mostly trimmed down to 1MB, so it won’t block long. Can be
   preloaded on server to avoid locale switching.
   - Support for most likely subtags - v2.0, covered.
   - Options in the resolved locale tag - return information being
   supported (and if was asked for). Drop other extensions. If user passes
   th only Eric says that we get back -u-nu-thai in addition (a bug).
   - Bound format methods - compare is bound others are not. Make format
   methods bound.
   - resolvedOptions - should we create a new object or allow for cached
   value to be returned? Should the object be mutable? Should resolvedOptions
   become a method to lower the confusion? Make it a function that returns
   a mutable object.
   - Lookup algorithm spec change - NOTE -> MUST for zh-TW problem. Make it
   a normative must.
   - Luke: editorial comment - left for later/es-discuss.
   - Alex/Allen: remove LocaleList object and use plain Array.

*

Nightly build of Chromium with i18n API

Nebojša Ćirić — 2012-05-21T18:48:01

http://commondatastorage.googleapis.com/chromium-browser-continuous/index.html?path=Mac/138094/

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

Internationalization: Comments to 1st Edition / Draft 3 May 2012

Steven R. Loomis — 2012-05-21T17:37:48

Comments to 1st Edition / Draft 3 May 2012

These are very similar to previous comments.

** >> p1, 3: Need update to later version of specs: Unicode, CLDR. 
Especially with requested updates to CLDR.

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

** >> Much specification of how the API machinery operates, but not 
about the expected output.

** >> 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.

** >> p21-22, p25, p26: again, need more examples to evaluate this.

** >> 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?

Subclassing ECMAScript arrays with Array.create(arrayPrototypeObject)

Henri Manson — 2012-05-21T16:23:13

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< at >public.gmane.org
https://mail.mozilla.org/listinfo/es-discuss

WeakMaps functionality, within regular object semantics

Hugh Jackson — 2012-05-21T14:24:55

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] // -> '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 that the reason type of thing isn't in the
proposal is that there's a some glaring semantic or implementation issue;
but I thought it'd be worth mentioning anyway.  If not only because of the
comparative neatness of the syntax, perhaps also for helping keep the
language cohesive as it grows.

Best,

Hugh

ECMA-262 purview? was re: FFT module

Wes Garland — 2012-05-21T11:19:48

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 <jussi.kalliokoski-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

ToNumber("0b1001")

Domenic Denicola — 2012-05-21T08:55:41

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< at >public.gmane.org
https://mail.mozilla.org/listinfo/es-discuss