gmane.comp.lang.javascript.ecmascript4.general

host object interface and host object plugins (Re: ECMA-262 purview?was re: FFT module)

Claus Reinke — 2012-05-24T15:44:10

You mean like there is only one major browser implementation?-)

Just because one implementation currently has the most steam,
that doesn't mean that there is only one implementation to consider.


When the Haskell FFI was in development, there were three Haskell
implementations participating, from a bytecode compiler and interpreter
written in C -aiming for small and portable implementation-, over a
compiler written in Haskell -aiming to generate memory-efficient
code-, to a heavily optimizing compiler written in Haskell -aiming
to generate time-efficient C.

These implementations' pre-standard approaches to FFI were so
different that multiple tools had sprung up to preprocess code for
the implementation-specific FFIs.

Today, I have no idea how many Haskell implementations there are,
but at least three of them are still in development and support the FFI.
Only one implementation is in both sets, currently the most popular
(which implementation is most popular has changed several times
over the years, as has the backend of the one implementation that
was in both sets).


The odds depend on the goals. Your arguments imply that you think
of the usual FFI, giving access to anything implemented in the underlying
platform that has a C interface. That would explain your safety concerns.

As a minimalistic counterpoint, consider a FFI that only provides access
to functionality from some standard device API (which I'll abbreviate as
sdAPI here). That is, the existing sdAPI processes still decide what is
available and safe, as they do now; the FFI describes how to use such
safe functionality, and how to implement access to it.

Currently, sdAPI functions are agreed on and spec-ed, then implemented,
hopefully by more than one implementation. Client code knows about
functionality because coders read the spec and feature test whether using
the spec-ed functionality works. In other words, the defacto FFI is dynamic.
Invoking sdAPI functionality might trigger permission requests, unless
sufficient permissions have been obtained beforehand. Without permissions,
the functionality will fail. Permissions are also dynamic.

There are other batches of non-JS functionality that JS implementations
currently provide JS code access to: DOM-related in browser JS code,
OS-related in server-side JS code, chapter 15-related in some JS
implementations. The functionality differs and is spec-ed by different
bodies, but the FFI used to access that functionality should be similar,
shouldn't it?

--- host objects as ES FFI
The current basis for all this in the ES spec are host objects. ES5.1 talks
about host objects themselves being beyond the scope of its specification
but places constraints on such host objects. These constraints comprise
the current (implicit) ES FFI. There is no comment on discoverability, on
permissions, there is lots of "implementation-dependent". In particular,
there is the implicit expectation that there is a single monolithic host
environment - to change available host functionality, one changes the
host. This is the foundation for current practices wrt importing host
objects into JS code.
---

Now, one of the cornerstones of ES6 are modules, which -among other
things- try to replace one level of runtime checks with loadtime checks:
if a module loads successfully, its toplevel exports will be available and
are known to support the client's imports.

One may wonder whether ES6, with modules, might not improve on the
host object aspects of ES5. Perhaps in such a way that if a JS module loads
successfully, it is known that the host objects it tries to use/import are
indeed available (permission would still be dynamic).

To throw some wild ideas in the air: one could import host objects from
a Host module; one could organize the Host namespace according to
specification bodies (server-side, browser, DOM, device, ..); or one could
go with the traditional FFI approach that host objects need to be declared
in code, where the declaration compiles only if the host object is 
available;
then, one could provide and import modules consisting only of such host
object declarations, as needed; ..

Without fixing on concrete proposals, but code might look like this:

    // host modules, each under control of a spec body
    // if the JS implementation has access to code implementing
    // such a host module, the import succeeds; at runtime, the
    // host module might implement additional permission protocols

    import document from DOM
    import camera from Cordova
    import read from CommonJS.Filesystem.fs

or like this:

    // declare expected methods in host objects
    function Array.prototype.forEach(cb,th) { "use host" }

Perhaps you prefer to call it host object interface (HOI) instead of foreign
function interface (FFI). The point is that there is an interface that the 
ES
spec has something to say on, that could be improved in line with the
ES5 to ES6 transition, and that could be supported in JS implementations,
without tc39 having to interfere with other existing standards bodies.

The host object interface is simply the way to give JS code access to
the host objects standardized by other bodies.


What makes you think that the Haskell FFI group had any influence
on OS or C compiler vendors?


Yes, I was referring to hybrid apps. Using the Phonegap example, they
prototype device API with the express intention of their prototype
implementations becoming mere shims for standard APIs as those
evolve.

The case for a standard JS FFI in this context is that they have APIS
that have become standard, they have implementations of those APIs
on devices, and they have JS implementations on the same devices,
but they have no direct/standard way of extending the JS
implementations with access to those API implementations.

If there was a standard JS FFI supported by JS implementations,
including a way to extend the set of host objects without rewriting
the JS implementation, then that could be used instead of the
workarounds that current Phonegap implementations have to use.
Most likely such an in-browser host object access would be more
efficient and amenable to optimizations than the workarounds.

Even if I load JS code from the web that wants to import and
use device access, and I happen to have code for accessing that
device feature installed, the JS code will not get to use the feature
unless I enable my browser's access to the device access code.

But if I decide to enable the feature, I do not have to wait for
the browser to implement it, the browser can be extended by
using "host object plugins".

tc39 does not have to join/repeat the security discussions
going on in other committees - it specifies the host object interface.
Browser implementers support the host object interface with
a host object plugin API. As a first approximation, the plugin
API would have a whitelist of standards that are known to have
addressed safety concerns. Users install host object plugins
from standards bodies they trust, and if their browsers share
that trust, the plugins can be used with the security protocols
defined by those standards. Without having to update the browser.


I'm not saying it would be easy. Just that it would be worthwhile.
And that it could be done in small steps, starting with the current
host object specification in ES5.


Javascript special position as being transferred and compiled almost
on every use mean that things like LLJS hold a lot of promise: just as
minimizers optimize JS source for transfer, pre-compilation to LLJS,
or to an explicitly typed future ES.harmony, can help final compilation
at the usage sites. I am looking forward to those developments.

But that doesn't extend the set of accessible host objects.


The current ES FFI is the host object specification. It "is" and it
constrains/hinders current practice and experimentation with emerging
standards. If you do not want to improve that, that is your decision. I am
merely asking about an opportunity I see for improving the foundations
of current practice.


When do you expect to see those device APIs in IE? Shorter paths
win in the short term, even if only few can walk them. But if they are
successful, it is possible, as you like to say, to pave those cowpaths.

For Gecko and WebKit, it may just be a different way to implement
the same specs, but if _all_ browsers support a host object interface,
further API development can be decoupled from browser versions.


I cite Haskell experience because that is what I happen to be most
familiar with. I only cite it when it is relevant. Please don't object to
Haskell experience by default just because it is Haskell. A lot of good
work has gone into that language.

Some posters here are familiar with Smalltalk, some with SML,
some with Scheme, some with Haskell, some with other languages -
I think it is great that ES design can profit from such a broad range
of experience.

Claus

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

Re: TC39 meeting Wed 5/23/2012

David Bruant — 2012-05-24T12:46:49

Thanks for the notes and complements :-)

Le 24/05/2012 04:43, Brendan Eich a écrit :
I don't know who are "people" but I'm not one of them. <| offered some 
nice sugar with regard to constructors. Just sugar but it was convenient.

It seems that "delete Object.prototype.__proto__" would be the first 
line I'd write if I wanted to prevent __proto__ from being harmful.
However, since <| is out, after doing the delete, the use cases it was 
intended for (array subclassing is zepto.js' use case, right?) cannot be 
achieved anymore.

I think we can only recover is if it's possible to extract a proto 
setter before the delete. I haven't seen a resolution on the 
__proto__-related notes, but considering that <| is out, can it be 
consider to just do a setter?


Once we're at it, for the sake of completeness there is probably no harm 
in adding a Reflect.setPrototype at this point, is there?

David

Re: minutes, TC39 meeting Tues 5/22/2012

Aymeric Vitte — 2012-05-24T11:51:33


Le 23/05/2012 22:30, David Herman a écrit :
I know writters don't have always time but maybe adding more examples 
and simple ones (even not reflecting the whole picture) in the strawmans 
would help a lot. For example the fat arrow strawman is very condensed 
for what it brings and it took some time before I start understanding 
what the soft binding strawman was about. Example of simple examples 
(hope this is correct) :

Soft binding :

var o={
     msg:'I am o',
     log:console.log(this.msg)
}

var o2={
     msg:'I am o2'
}

o2.log=o.log;

o2.log();    //"I am o"
                    //without soft binding it should be "I am o2"

Lexical this (and dynamic this) :

var test='aaa';

var o={test:'bbb'};

var o2={test:'ccc'};

//without lexical this
o.m=function() {var self=this; var func=function() 
{console.log(this.test+' '+self)};func()};

var f=o.m;

o2.m=o.m;

o.m();    //aaa bbb
               //this.test is not o.test

o2.m(); //aaa ccc
               //this.test is not o2.test

f();    //aaa aaa

//with lexical this
o.m=function() {var self=this; var func=()=>console.log(this.test+' 
'+self);func()}

var f=o.m;

o2.m=o.m;

o.m();    //bbb bbb
               //this.test is o.test
               //lexical |this| is associated to dynamic |this| outside func
               //you don't need the var self=this statement

o2.m(); //ccc ccc
              //same as above

f();    //aaa aaa

//other example
o.m=()=>{console.log(this.test)};

var f=o.m;

o2.m=o.m;

o.m();    //bbb

f();     //bbb
           //should be aaa if no lexical this

o2.m(); //bbb
               //should be ccc if no lexical this

Re: minutes, TC39 meeting Tues 5/22/2012

David Bruant — 2012-05-24T11:07:06

Le 24/05/2012 07:13, Brendan Eich a écrit :
Source map makes this even easier and smoother. In his JSConf 2012 
presentation, Paul Irish mentionned that source map could work with 
Traceur. To keep in mind.

David

Re: TC39 meeting Wed 5/23/2012

Herby Vojčík — 2012-05-24T09:44:53

Any chance to get this back to any (constructor or concise method) 
functions?

Herby

RE: minutes, TC39 meeting Tues 5/22/2012

Domenic Denicola — 2012-05-24T05:48:52

From: Rick Waldron [mailto:waldron.rick-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org] 



Indeed you're right, that is what I meant to say. Apologies to Erik, and thanks to JJB for pointing out Traceur is much better suited for my purposes than I thought. I will definitely give it another try.

Re: minutes, TC39 meeting Tues 5/22/2012

John J Barton — 2012-05-24T05:38:52

On Wed, May 23, 2012 at 10:08 PM, Domenic Denicola
<domenic-oZxxhNEIM/0UaOvFRw7EvkEOCMrvLtNR< at >public.gmane.org> wrote:

Each feature in Traceur is individually controlled by options, so you
can use your own judgement and turn off any feature you don't believe
will make it in to ES-6.  Traceur is open source and your
contributions would be welcomed. It's pretty easy to work with.

jjb

RE: minutes, TC39 meeting Tues 5/22/2012

Domenic Denicola — 2012-05-24T05:26:16

You are of course right, Brendan, and thanks for addressing my points. Certainly part of this was fueled more by frustration than informed knowledge (see below).




Fair point. I think I and others would be reassured if we had some analogies drawn with the HTML5 timescale: e.g. how long from <article>, <section> etc. until they got included in default browser stylesheets, or how long from <input type="date"> to browser UIs. (That last one is actually a pretty good example of slow implementation progress; I feel a lot better about ES6's progress when I think about how we are just now getting a UI for <input type="date"> in Chrome.)


The proxies, or Node.js? In either case, great news! And in either case, how did you learn about this? I try to stay up to date on all relevant blogs, Twitter feeds, mailing lists, etc., but certainly could have missed one. If it was private communication, perhaps in the interest of helping developers see ES6 progress (as per Brandon's original point) such things could be more publicized in the future? I imagine that's complicated though.


I guess I can't really expect to see all the signs through public channels, as above. Still, I think opening such channels would be a valuable thing for the community.

Re: minutes, TC39 meeting Tues 5/22/2012

Rick Waldron — 2012-05-24T05:23:15


On Wednesday, May 23, 2012 at 10:08 PM, Domenic Denicola wrote: 

I just used Traceur 2 days ago and wrote max/min style classes.

 

There is a lot of support and interest for the mustache in TC39
 


I don't think this is a fair claim to make, considering Traceur had no real attention for quite some time and Erik Arvidsson really stepped it up to get a nice cross section of features prototyped in a short amount of time. I think what you meant to say was "thank you".

 

Blaming TC39 for IE's slowness is about as appropriate as blaming me for the Boston molasses disaster.

Some feedback about your feedback:   I'm wondering if you have any thoughts about the actual minutes?


Rick
 


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

Re: minutes, TC39 meeting Tues 5/22/2012

Brendan Eich — 2012-05-24T05:13:45

Remember, HTML5 started in 2004 (WHATWG founding) and still isn't done. 
Eight years ago.


That'll be fixed this year, soon I'm told.


How would you see the signs? Just asking. I know the Munich team is 
going strong and they have skills. I don't know detailed schedule, but 
there is no need to presume inaction or action. Let's ask.


This is all true now, but with more balanced browser competition and 
IE10 coming along, next year is a different story.

If there were a way to make this go faster, I'd want it. I don't know of 
a way. Do you? Again, HTML5 isn't done, isn't totally 
cross-browser-consistent, and started 8 years ago.

Compilers do seem attractive, not only for ES6-prototyped to ES5, but 
for even more advanced/experimental languages (LLJS, for example). 
CoffeeScript is quite usable, too.

/be

RE: minutes, TC39 meeting Tues 5/22/2012

Domenic Denicola — 2012-05-24T05:08:39

The prototyping efforts are appreciated, but can rarely be used in a comfortable way. (Compared to, say, HTML5.) I've thought a lot about how to feasibly use Harmony features in real-world code, but have fallen down every time. Here are some of the stumbling blocks I've encountered:
 
* Node.js with --harmony flag gets you collections, old proxies, and (significantly) block scoping. But Node does not make it easy to indicate "this file needs to be run with --harmony," or e.g. to require harmony-using files from non-harmony-using libraries. So this ends up being a nonstarter for library authors, leaving it only usable by application writers. Besides, the proxies are still old, which is really unfortunate. And the iteration rate is slowww: stuff like destructuring has been harmonized for a long time, but shows no sign of making it into V8.

* The same problems apply to desktop apps written with Chromium Embedded Framework. These will probably have more app code, but then if you want to factor any of it out into smaller redistributable modules, you limit your audience.

* SpiderMonkey has a lot of stuff that we would love to use, and a fairly fast iteration time. (Direct proxies are almost landed, according to my bugmail!) The spec is tracked pretty well, too. But SpiderMonkey has very little uptake outside of Firefox, and most code written for Firefox must be web-compatible, so nobody except Firefox extension authors gets to use its many features.

* Traceur seems to be coming along nicely, but its alignment with the spec leaves a lot to be desired. Destructuring just got fixed a few days ago, and they have a class syntax you have to avoid to write ES6-as-it-is--compatible code. They have features like private names that are not (really) in the spec yet, using speculative syntax (`new Name` was never harmonized, was it?). Monocle-mustache is in, somehow. Etc. It's ES6-like, but doesn't reflect TC39's actual progress, instead reflecting the Traceur team's interpretation of where TC39 might eventually, hopefully, end up. Subsetting might be a solution, assuming the semantics of the subsetted features are aligned with the spec, but determining that would require further investigation.

* And of course there's the usual elephant in the room, viz. Internet Explorer. We (Barnes & Noble.com) reached out to Microsoft about including some basic, already-harmonized features in IE10 for use in writing desktop apps in HTML5/JS as per their new Windows Runtime framework. (This was desired since we are using some of them in our existing Chromium-based desktop app, namely block scoping and weak maps.) But even as a "first class partner" (or something), they were unable to grant us this request. The attitude that I personally inferred was that ES6 won't make it into IE before a finalized spec is available. This not only stalls web progress, but also that of anything that embeds Chakra (a fairly common operation on Windows, about to become much more common with Windows 8).

Re: TC39 meeting Wed 5/23/2012

Norbert Lindenberg — 2012-05-24T04:43:59

A few additional notes on the items related to internationalization.

Norbert


On May 23, 2012, at 17:58 , Rick Waldron wrote:


I've inserted a copy of my proposal into the Harmony section of the wiki (I wish the wiki had better support for content created in HTML...):
http://wiki.ecmascript.org/doku.php?id=harmony:unicode_supplementary_characters
and updated Allen's proposals, one to indicate that it's been superseded, the other to indicate that it's still valid and complementary to the accepted proposal:
http://wiki.ecmascript.org/doku.php?id=strawman:support_full_unicode_in_strings
http://wiki.ecmascript.org/doku.php?id=strawman:full_unicode_source_code

More detail on the regular expression issue mentioned:
https://mail.mozilla.org/pipermail/es-discuss/2012-May/022665.html 


The basis for the discussion were:
https://mail.mozilla.org/pipermail/es-discuss/2012-March/020830.html
https://mail.mozilla.org/pipermail/es-discuss/2012-March/020832.html

Sections to be updated for Harmony are 15.9.1.7 and 15.9.1.8.


The reason is that this operation would break a string into UTF-16 code units, so supplementary characters would be broken up. The same functionality (with the same problem) is already available as str.split(""); there's no need to make this problematic functionality more convenient.

Re: TC39 meeting Wed 5/23/2012

Rick Waldron — 2012-05-24T03:51:45

Thanks for filling in those blanks  

-Rick


On Wednesday, May 23, 2012 at 7:43 PM, Brendan Eich wrote:


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

Re: minutes, TC39 meeting Tues 5/22/2012

Brendan Eich — 2012-05-24T02:46:12

Ok, if you are just the messenger I won't shoot you ;-).

Of course, thanks to https://github.com/JSFixed/JSFixed we know you're 
relaying real messages, although noisy. I'm relying on < at >valueof, 
< at >rwaldron and others to sift out the signal.

Angst and exaggeration aside, there is a fair point here. JS is not 
evolving as fast as its libraries and compilers (hence Mozilla's 
research in Emscripten and LLJS). We need to do better, both on just 
communicating what we've already done (which often satisfies the angst-y 
folks), and in helping browsers show progress via prototypes that verge 
on de-facto and then de-jure standards.

Working on this, so is dherman (so are others).

/be

Brandon Benvie wrote:

Re: TC39 meeting Wed 5/23/2012

Brendan Eich — 2012-05-24T02:43:00

Rick, thanks for taking these. I'll try to add a bit of explanation 
where it looks like "you had to be there" ;-).

/be

Rick Waldron wrote:

BE: let's subset the parts of Hixie's HTML5 spec that we need, and no 
more (and reference that spec so it's likelier we keep the subset relation). 



Allen's point was that all of the strawman champions and Allen, the spec 
editor, and experts and interested folks (Tom Van Cutsem, people on 
es-discuss) all need to digest the non-local effects of the local but 
low-level changes in the strawman.

I said this, and also offered that we would prototype in SpiderMonkey 
alongside V8.


I emphasized that all strawman not moved to deferred: namespace in the 
wiki (and there's a curation process here, which can fail sometimes) are 
fair game for prototyping.


Rather, "Object Literal" or "Property Definition" (in ES3, 
PropertyAssignment) shorthand.


That is, we keep the shorthand for *structuring* as well as for 
*destructuring* where it is clearly useful.

LH observed that the 90%+ by frequency use-case for destructuring wants 
the shorthand, whereas for structuring (making an object via an object 
literal expression) it's more like 10% or 1%. BE agrees but BE and MM at 
least want duality consistency: shorthand for both literals and patterns.

That's where we left ES6.

I personally think the "n00bs will see the new shorthand and 
artificiailly declare variables of the same name as the property just to 
use the shorthand" worry as an undemonstrated speculation, and too 
fearful. We need user-testing evidence of this!

EA raised the other interpretation of {x,y} in an expression, as a 
WebIDL-ish enum equivalent to {x: "x", y: "y"} -- for making string 
manifest constants named by the string contents -- but this is a 
different semantics, and rarer yet than {x,y} to make a point from x and 
y bindings.

AR mentioned future-hostility to set notation in JS. BE ack'ed that, 
figures it is un-possible given object literals being wrapped in curlies 
anyway.


I.e., we defer/cancel triangle and go with normative mandatory 
__proto__. W00t! Kidding, mostly, but I perpetrated it, it is in all 
browsers but IE, and IE feels the heat on mobile (thank you Thomas 
Fuchs!). So __proto__ is the winner already, we're just trying to 
forestall the inevitable.


Further choice: allow = instead of : in object literals too, not just in 
mustache-literals!


Ah, you got that one. Thanks.

OH worried that the JSON theft attack (a global setter targeting 
well-known id in top-level JSON blob) would work, but this requires both 
= instead of : in the JSON blob, and the wrong MIME type for loading 
JSON as a <script>.


I still want mustache. My advice was to copy and lightly mutate the 
ObjectLiteral grammar instead of reusing it, to allow = and : as 
alternatives for assign and define, respectively; and for any other 
reason. Sometimes pattern languages diverge from expression grammars for 
good reason.


But just to capture all the nuance, the idea of < at >privateName: value in 
an object literal has support and maintains the compile-time name 
structure that EA rightly cited.

The [anyExpr]: value idea for a property definition in an object literal 
is what I believe died today. If you want to extend an object with a 
computed property name, use assignment or Object.defineProperty.


BE: valid use-case for observers, virtualization layers, other such 
bridging functions. MM/AWB need to discuss more, ideally here on es-discuss! 


See https://bugzilla.mozilla.org/show_bug.cgi?id=749786 and stay tuned.

Thanks again, Rick!

/be

Re: minutes, TC39 meeting Tues 5/22/2012

Brandon Benvie — 2012-05-24T02:31:38

It's not really my opinion. I spend all day playing with this stuff. But
it's what I hear in ##javascript on freenode all the time and the general
sentiment I see in blogs often enough. That the movement is slow enough,
combined with cycle time of browser generations, that (from
my observations) that people don't connect with how ES6 may benefit them
because they never expect to use it, not within the forseeable future.
Perhaps this is a misread on my part, it doesn't reflect what I personally
think or do.
_______________________________________________
es-discuss mailing list
es-discuss-4eJtQOnFJqFAfugRpC6u6w< at >public.gmane.org
https://mail.mozilla.org/listinfo/es-discuss

Re: minutes, TC39 meeting Tues 5/22/2012

Brendan Eich — 2012-05-24T02:20:06

Play fair now. SpiderMonkey in Firefox prototyped let, const, 
generators, iterators (an earlier form), destructuring (close to final 
ES6), comprehensions, generator expressions, and more recently proxies, 
weak maps, maps, and sets. V8 joined in the proxies, weak maps, maps, 
and sets fun. The for-of loop from ES6 is in SpiderMonkey now. Most 
significantly, modules are under way in SpiderMonkey and V8.

We prototype as we go. V8 has kept stuff under a flag and that's fair -- 
we may do likewise, certainly with new stuff likely to change, in 
SpiderMonkey. But saying nothing is coming out of TC39 is inaccurate.

If you mean classes are not being prototyped because 'const class' or 
equivalent is not part of the almost-at-consensus "maximally minimal 
classes" strawman, you're right. If we must have a way to fix the 
properties of a class instance as Waldemar wishes, then I predict 
classes won't be in ES6 and it will be hard to justify prototyping less 
than the full required (as yet unwritten) proposal that satisfies 
everyones' wants.

That is a shame, and a stain on TC39's escutcheon. But you should be 
accurate about the many other things we have done, which are coming along.

/be

Brandon Benvie wrote:

Re: minutes, TC39 meeting Tues 5/22/2012

Brandon Benvie — 2012-05-24T02:00:47

The last discussion point there is really important I think. I get a strong
sense of the general JS developer world feeling no connection at all to
this process, and much can be put directly on the sheer timescale. We've
seen 2 month browser version cycles come in force, the "living standard"
that is HTML5 and the as of recent rapid movement of new APIs coming out to
JS from not-TC39. People don't feel connected to the things in ES6 because
they rightfully can't envision using them in an imaginable timeframe.
_______________________________________________
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

Re: minutes, TC39 meeting Tues 5/22/2012

Waldemar Horwat — 2012-05-23T22:21:56

Since you're speculating on my position, here it is:

- Classes don't hang together unless we have agreement on some declarative way to specify properties, referred to as "const classes" in the meeting notes.
- It's fine for that to not be the default, but we must have agreement on how to do it.

I'll be out of the office for a few days, but we can discuss it when I'm back.

     Waldemar