Re: Improving Function.prototype.bind

[Mark S. Miller]

In your proposal, what does this code sequence do:


Object.boundTo(Object).foo = capabilityBobShouldntGet;
var HAH = Object.boundTo(Object).foo;

?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Improving Function.prototype.bind

[Andrea Giammarchi]

most JS developers use what their library/framework provide and the bind is
most of the time transparent.

Libraries developers simply use bind as a Santa Claus ES5 gift so they
don't bother thinking about the pattern they are forced to use, they just
use bind the way they can but again, not relying in fresh new objects per
context.

My code, in my blog, is using same WeakMap concept, except is not using
WeakMap ... I can hardly think of a browser that implements Harmony WeakMap
but not Function.prototype.bind yet

Finally, accordingly with @Mark reply, I think it's still not clear what I
am talking about ... so here the signature/spec:


Object.prototype.boundTo(callback:Function):BoundObject

The method accepts one argument only and this must be one with [[Call]]
capabilities (a Function/callable, nothing else)

The BoundObject is a singleton generated with the unique combination of the
current generic object that is calling the boundTo method, and the given
Function argument.

The behavior of this BoundObject is exactly the same of

callback.bind(genericObject)

except it's a singleton.

A smart implementation should be able to release this singleton once the
genericObject that invoked boundTo has reference counter equals to zero and
of course, if nothing else is holding the BoundObject explicitly ( but in
that case the reference counter of genericObject cannot be zero so ... )

If latest point is "too smart/complicated" then the signature would be

Object.prototype.boundTo(callback:Function[,
erase:Boolean=false]):BoundObject

where a call to

genericObject.boundTo(callback, false)

should be able to return the BoundObject in any case but destroy it
internally.
Latter point is mainly for shims and I think not needed.

Accordingly with this, everything that Mark wrote in his last reply could
not happen ... everything will work as expected.

Any better ?

I can try to explain even more, if necessary, or provide better
specifications aligned with current ES5 terminology

Best Regards,
Andrea Giammarchi

P.S. is it really just me that see the problem with current bind ?

On Fri, Jan 6, 2012 at 2:22 AM, Brendan Eich  wrote:

> On Jan 5, 2012, at 4:47 PM, Andrea Giammarchi wrote:
>
> Right now the lack of memoization is not a burning issue, from what I
> hear. You've raised it, I think for the first time on es-discuss.
>
> /be
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Allen Wirfs-Brock]

On Jan 5, 2012, at 10:20 PM, Mark S. Miller wrote:

> 
> 
> On Thu, Jan 5, 2012 at 10:13 PM, Allen Wirfs-Brock  
> wrote:
> 
> On Jan 5, 2012, at 8:24 PM, Mark S. Miller wrote:
> 
>> Hi Allen, if ES5 had only one mode, I'd understand this. But I thought we 
>> were trying to arrive at two modes, ES6 non-strict, to be backwards compat 
>> with ES5-non-strict, and ES6 strict, to be backwards compat with ES5-strict. 
>> I am perfectly happy to call ES6 non-strict "ES3", since ES5-non-strict 
>> really exists to be an ES3 compatibility mode, and was constrained to be 
>> backwards compatible from ES3. Likewise, I am happy to call the new ES6 
>> strict simply "ES6".
>> 
> 
> When I talked about "ES5" in my original post I meant full ES5 including both 
> strict and non-strict modes.  Since ES6 is supposed to be a strict super set 
> of ES5 strict mode, anything in the ES5-only category must be an exclusively 
> non-strict mode feature (for example, with).  I suppose you could call that 
> category "ES3" but I decided to label it "ES5-only"  to keep things focused 
> on differences between ES5 and ES5.
> 
>> Concretely, I am confused how your transition diagram is supposed to handle 
>> "use strict";. Reading your state machine literally, since "use strict"; is 
>> accepted by ES5, if it is accepted by ES6 (as I think we all agree it would 
>> be), then it would leave us in state ES5&ES6. Were you two base categories 
>> "ES6 non-strict" (or ES3) and "ES6 strict" (or ES6), then a "use strict"; 
>> would put us in your ES6 strict (or ES6) category, which is what I would 
>> have expected.
> 
> Yes, "use strict" is in the ES5&ES6 category.  A ES5 completely strict mode 
> program would start in State 5&6  and stay in that state for its entire 
> "compilation".  Only encountering use of a new ES6 feature would case a 
> transition to State ES6.  Looking at it another way, Both State ES5 and State 
> 5&6 include support for both strict and non-strict ES5 code.  State ES6 only 
> allows strict code.
> 
> Them either I still don't understand, this proposal is broken, or we're 
> talking about three modes. Take the following three programs:

My point wasn't to try to define modes. I think that is where we are 
miscommunicating. 

There are exactly two language specifications we have to deal with.  The ES5 
spec. and the ES6 spec. A given ES source program may conform to one, or the 
other, or both (or neither).  The exercise I was working through is how do you 
determine whether to process a given source file according to the ES5 spec. or 
the ES6 spec., without explicitly preassociating the source file with one or 
another.  That is what my state machine does.  It starts assuming the source 
file is in the intersection, where it it doesn't matter which specification you 
apply.  As soon as it see a feature that is unique to one or the other  of the 
specification it clamps to that specification for the entire program.  The 
extra states are to deal with the situation where the appropriate specification 
to use for a feature can not be  directly inferable from the syntax of the 
feature. 


> 
> 1) program using only ES3 features and no "use strict";
> 
> 2) program using only ES5 strict features and saying "use strict";
> 
> 3) program using ES6-only features.
> 
> Do these three programs operate in three different modes? If not, do #1 and 
> #2 operate in the same mode, or do #2 and #3 operate in the same mode?

It isn't about "modes".  #1 and #2 are ES5 programs and are processed as such 
(applying/not the appropriately strictness as per ES5) . #3 is an ES6 program 
is processed as such (including using the strict semantics that are universal 
to ES6).


> 
> Putting #1 and #2 into the same mode breaks ES5 code. So to avoid three 
> modes, my conclusion is that #2 and #3 must be in the same mode. But that 
> does not seem to be what you're saying. What am I misunderstanding?
> 
> 
> -- 
> Cheers,
> --MarkM

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: ES6 doesn't need opt-in

[Luke Hoban]

Jumping in late, and possibly repeating some already covered ground, but this 
is clearly an important topic.

Looking at all the proposals on these threads, I have to throw support behind 
Mark's proposal below, or a close variant of it as discussed below and in some 
of the other branches (I think this is close to what Brendan has been 
advocating as well?).  Let me try to motivate this from a somewhat different 
direction.  Wall of text below - but the punchline is:

Let's avoid versioning by making (almost) no breaking changes.

# Versioning #
There are two goals to versioning - (1) allow breaking changes that code can 
explicitly opt-in to and (2) support reasonable forward compatibility of new 
code running on old runtimes.

The original plan for ES6 was to support (1) and (2) via a versioned script 
tag.  This allowed breaking changes because it was explicit opt in, and 
supported forward compatibility to the extent that there was graceful 
degradation of behaviour on old runtimes (skipping the script block).

Versioned script tags are onerous though, and folks are rightly looking for 
better options.

The better option is to not do versioning at all.  To do that, you need to give 
up on (1) and (2).  That is - no breaking changes (or at least no practically 
significant ones), and no 1st class support for forward compatibility.

# Forward compatibility #
The forward compatibility point in favor of a versioned script tag was never 
particularly strong anyway.  A versioned script tag is ignored on most down-rev 
browsers, but it is still hard to construct programs using new syntax that 
behave pleasantly on those browsers, because the granularity of feature 
detection is at the script-block level, not the application-feature level.  To 
the extent that apps want to use new syntax and still work on older browsers, 
they can almost as easily just accept the early errors from their 

Re: ES6 doesn't need opt-in

[Mark S. Miller]

On Thu, Jan 5, 2012 at 10:13 PM, Allen Wirfs-Brock wrote:

>
> On Jan 5, 2012, at 8:24 PM, Mark S. Miller wrote:
>
> Hi Allen, if ES5 had only one mode, I'd understand this. But I thought we
> were trying to arrive at two modes, ES6 non-strict, to be backwards compat
> with ES5-non-strict, and ES6 strict, to be backwards compat with
> ES5-strict. I am perfectly happy to call ES6 non-strict "ES3", since
> ES5-non-strict really exists to be an ES3 compatibility mode, and was
> constrained to be backwards compatible from ES3. Likewise, I am happy to
> call the new ES6 strict simply "ES6".
>
> When I talked about "ES5" in my original post I meant full ES5 including
> both strict and non-strict modes.  Since ES6 is supposed to be a strict
> super set of ES5 strict mode, anything in the ES5-only category must be an
> exclusively non-strict mode feature (for example, with).  I suppose you
> could call that category "ES3" but I decided to label it "ES5-only"  to
> keep things focused on differences between ES5 and ES5.
>
> Concretely, I am confused how your transition diagram is supposed to
> handle "use strict";. Reading your state machine literally, since "use
> strict"; is accepted by ES5, if it is accepted by ES6 (as I think we all
> agree it would be), then it would leave us in state ES5&ES6. Were you two
> base categories "ES6 non-strict" (or ES3) and "ES6 strict" (or ES6), then a
> "use strict"; would put us in your ES6 strict (or ES6) category, which is
> what I would have expected.
>
>
> Yes, "use strict" is in the ES5&ES6 category.  A ES5 completely strict
> mode program would start in State 5&6  and stay in that state for its
> entire "compilation".  Only encountering use of a new ES6 feature would
> case a transition to State ES6.  Looking at it another way, Both State ES5
> and State 5&6 include support for both strict and non-strict ES5 code.
>  State ES6 only allows strict code.
>

Them either I still don't understand, this proposal is broken, or we're
talking about three modes. Take the following three programs:

1) program using only ES3 features and no "use strict";

2) program using only ES5 strict features and saying "use strict";

3) program using ES6-only features.

Do these three programs operate in three different modes? If not, do #1 and
#2 operate in the same mode, or do #2 and #3 operate in the same mode?

Putting #1 and #2 into the same mode breaks ES5 code. So to avoid three
modes, my conclusion is that #2 and #3 must be in the same mode. But that
does not seem to be what you're saying. What am I misunderstanding?


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Allen Wirfs-Brock]

On Jan 5, 2012, at 8:24 PM, Mark S. Miller wrote:

> Hi Allen, if ES5 had only one mode, I'd understand this. But I thought we 
> were trying to arrive at two modes, ES6 non-strict, to be backwards compat 
> with ES5-non-strict, and ES6 strict, to be backwards compat with ES5-strict. 
> I am perfectly happy to call ES6 non-strict "ES3", since ES5-non-strict 
> really exists to be an ES3 compatibility mode, and was constrained to be 
> backwards compatible from ES3. Likewise, I am happy to call the new ES6 
> strict simply "ES6".
> 
When I talked about "ES5" in my original post I meant full ES5 including both 
strict and non-strict modes.  Since ES6 is supposed to be a strict super set of 
ES5 strict mode, anything in the ES5-only category must be an exclusively 
non-strict mode feature (for example, with).  I suppose you could call that 
category "ES3" but I decided to label it "ES5-only"  to keep things focused on 
differences between ES5 and ES5.

> Concretely, I am confused how your transition diagram is supposed to handle 
> "use strict";. Reading your state machine literally, since "use strict"; is 
> accepted by ES5, if it is accepted by ES6 (as I think we all agree it would 
> be), then it would leave us in state ES5&ES6. Were you two base categories 
> "ES6 non-strict" (or ES3) and "ES6 strict" (or ES6), then a "use strict"; 
> would put us in your ES6 strict (or ES6) category, which is what I would have 
> expected.

Yes, "use strict" is in the ES5&ES6 category.  A ES5 completely strict mode 
program would start in State 5&6  and stay in that state for its entire 
"compilation".  Only encountering use of a new ES6 feature would case a 
transition to State ES6.  Looking at it another way, Both State ES5 and State 
5&6 include support for both strict and non-strict ES5 code.  State ES6 only 
allows strict code.

Allen
> 
> 
> On Thu, Jan 5, 2012 at 6:37 PM, Allen Wirfs-Brock  
> wrote:
> Here is a possible set of rules for implicitly assigning ES5 or ES6 semantics 
> to a Program unit
> 
> In an "ES6" implementation, all constructs that can occur in a valid program 
> fit into one of these categories:
> ES6-only:  The construct is based upon syntax or static semantics rules that 
> only exist in ES6.  For example, a destructuring pattern
> ES5-only:  The construct is based upon syntax that or static semantics rules 
> that that are not in ES6. For example, use of a with statement t.
> ES5&ES6:  The construct has identical semantics in both ES5 and ES6.
> ES5~EAS6:  The construct has identical syntax and static semantics in both 
> ES5 and ES6, but differing semantics.  For example, accessing a formal 
> parameter after an assignment to the corresponding element of the function's 
> arguments object.
> 
> We can then use the following state machines to describes the processing of a 
> Program based upon the occurrence for these feature categories.  Initially 
> start in State 5&6:
> 
> State 5&6
> if current construct is in ES5&ES6, process using intersection semantics, 
> then goto State 5&6
> if current construct is in ES5~ES6, process using ES5 semantics then, 
> goto State Compat5
> if current construct is in ES5-only, process using ES5 semantics then 
> goto  State ES5
> if current construct is in ES6-only, process using ES6 semantics then 
> goto State ES6
> 
> State ES5
> if current construct is in ES5&ES6, process using intersection semantics, 
> then goto State ES5
> if current construct is in ES5~ES6, process using ES5 semantics, then 
> goto State ES5
> if current construct is in ES5-only, process using ES5 semantics then 
> goto  State ES5
> if current construct is in ES6-only, terminate with Error: invalid 
> combination of ES5 and ES6 features
> 
> State ES6
> if current construct is in ES5&ES6, process using intersection semantics, 
> then goto State ES6
> if current construct is in ES5~ES6, process using ES6 semantics, then 
> goto State ES6
> if current construct is in ES5-only, terminate with Error: invalid 
> combination of ES5 and ES6 features
> if current construct is in ES6-only, process using ES6 semantics then 
> goto  State ES6
> 
> State Compat5  (or have an analogous Compat6 state, and restart to State ES5 
> when necessary)
> if current construct is in ES5&ES6, process using intersection semantics, 
> then goto State Compat5
> if current construct is in ES5~ES6, process using ES5 semantics then, 
> goto State Compat5
> if current construct is in ES5-only, process using ES5 semantics then 
> goto  State ES5
> if current construct is in ES6-only, abort current compilation and 
> restart from beginning, starting in State ES6
> 
> Basically using any ES6 features makes it an ES6 program.  Using any ES5-only 
> feature makes it an ES5 program.
> Combining ES5-only and ES6 features results in an invalid program.
> If a Program can not be explicitly identified as either ES5 or ES6, it is 
> treated as an ES5 program

Re: Improving Function.prototype.bind

[Mark S. Miller]

Such a built in memoization, whether by boundTo or this enhancement to bind
itself, creates a fatal ambient communications channel.

// initSES initialization, freezing all built in primordials other than
the true global

// load Alice as a confined object graph

// load Bob as a confined object graph. Alice and Bob should not be
able to communicate
// Covert channels mean we might not be able to prevent them from
communicating bits
// But we must certainly prevent capability leaks

Alice says

Object.boundTo(Object).foo = capabilityBobShouldntGet;
or
Object.bind(Object).foo = capabilityBobShouldntGet;

Bob says

var HAH = Object.boundTo(Object).foo;
or
var HAH = Object.bind(Object).foo;

David's WeakMap approach elegantly avoid this problem, because Alice and
Bob can only communicate if they already share access to this WeakMap, in
which case they could already communicate anyway.



On Thu, Jan 5, 2012 at 5:22 PM, Brendan Eich  wrote:

> On Jan 5, 2012, at 4:47 PM, Andrea Giammarchi wrote:
>
> > Guys, by any chance we can go back into the topic?
>
> You'll have to polyfill Function.prototype.bind in the current world of
> pre-ES5 browsers. Why not then go on to wrap it in a memoizing version that
> uses a WeakMap if available (emulated with strong keys/values array-based
> implementation if not)?
>
> If you need this machinery, it's all doable. If we should evolve a Harmony
> bind or betterBind based on your experience and others, we can do that.
>
> Right now the lack of memoization is not a burning issue, from what I
> hear. You've raised it, I think for the first time on es-discuss.
>
> /be
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Fwd: [friam] Fwd: Hash Collision Denial of Service

[Mark S. Miller]

There is currently an informal (partial?) consensus to try to add high
entropy identity hashes to ES6 (but no proposal page yet), so that users
can build hashtables for themselves. Were they to do so, they immediately
find they'd want to include non-objects as keys as well (like Map does),
and so we might be tempted to expose a stable data hashing function to
support such uses. The following surprised me, even though it was
apparently well known (not by me ;)) since 2003.

from :

Forwarded conversation
Subject: [friam] Fwd: Hash Collision Denial of Service


From: *Bill Frantz* 
Date: Thu, Jan 5, 2012 at 11:51 AM
To: Design 


From: @RISK: The Consensus Security Vulnerability Alert Week 1 2012

== Forwarded Message ==
Date: 1/5/12 19:37
From: 
ConsensusSecurityVulnerability**al...@sans.org(The
SANS Institute)

12.2.5 CVE: Not Available
Platform: Cross Platform
Title: Java Hash Collision Denial of Service
Description: Java is a programming language. The application is
exposed to a denial of service issue due to an
error during hashing form posts and updating a hash table. Specially
crafted forms in HTTP POST requests can trigger hash collisions
resulting in high CPU consumption. Java 7 and prior are affected.
Ref: 
http://www.ocert.org/**advisories/ocert-2011-003.html
http://www.securityfocus.com/**bid/51236/references
__**__**__

12.2.6 CVE: Not Available
Platform: Cross Platform
Title: Python Hash Collision Denial of Service
Description: Python is a programming language available for multiple
platforms. The application is exposed to a denial of service issue
due to an error during hashing form posts and updating a hash table.
Specially crafted forms in HTTP POST requests
can trigger hash collisions resulting in high CPU consumption.
All versions of Python are affected.
Ref: 
http://www.securityfocus.com/**bid/51239/references
__**__**__
== End Forwarded Message ==

It seems to me, short of using secure hashes, any use of hashtables is
subject to this attack if the attacker can control the data being hashed.

Cheers - Bill

--**--**
---
Bill Frantz|"We used to quip that "password" is the most common
408-356-8506   | password. Now it's 'password1.' Who said users haven't
www.periwinkle.com | learned anything about security?" -- Bruce Schneier

-- 
You received this message because you are subscribed to the Google Groups
"friam" group.
To post to this group, send email to fr...@googlegroups.com.
To unsubscribe from this group, send email to friam+unsubscribe@**
googlegroups.com .
For more options, visit this group at http://groups.google.com/**
group/friam?hl=en .


--
From: *Brian Warner* 
Date: Thu, Jan 5, 2012 at 12:09 PM
To: fr...@googlegroups.com


Given the limited number of output buckets, I don't think a secure hash
would win you much (i.e. there are no secure 10-bit hashes). Instead, I
think you want to mix things up a bit, by including a per-runtime random
secret in the hash calculation (generated each time the program starts,
maybe for each dictionary you allocate). And then hope that you don't
expose enough information to the attacker (perhaps by enumerating
dictionaries in "implementation-defined" order without sorting the keys)
to let them deduce the secret, and thus be able to force a lot of
collisions.

I was re-reading djb/agl's articles on "crit-bit trees" (aka PATRICIA
trees, or tries, for those in the router world), and making the argument
that programming languages should use a crit-bit tree as their
fundamental data structure rather than a hash-table -based dictionary
(because you get some additional operations for cheap, like sorted
enumeration). I'm not sure if this would be any less vulnerable to
attack.. seems like a series of [1,11,111,,1,..] keys would
cause similar problems.

 http://cr.yp.to/critbit.html
 https://github.com/agl/critbit


cheers,
 -Brian

--
From: *David-Sarah Hopwood* 
Date: Thu, Jan 5, 2012 at 2:03 PM
To: fr...@googlegroups.com


Huh. This is a class of attacks that I remember getting a lot of attention
in around 2003 [CW2003]. There were mitigations proposed then that sounded
reasonable (using universal hashing was one). Oh, but Java specifies a
stable
hash, so it's not fixable that way. That presumably explains why it's not
fixed.

[CW2003] Scott A. Crosby, Dan S. Wallach,
"Denial of Service via Algorithmic Complexity Attacks,"
Usenix Security Conference, 2003.

Re: ES6 doesn't need opt-in

[Mark S. Miller]

Hi Allen, if ES5 had only one mode, I'd understand this. But I thought we
were trying to arrive at two modes, ES6 non-strict, to be backwards compat
with ES5-non-strict, and ES6 strict, to be backwards compat with
ES5-strict. I am perfectly happy to call ES6 non-strict "ES3", since
ES5-non-strict really exists to be an ES3 compatibility mode, and was
constrained to be backwards compatible from ES3. Likewise, I am happy to
call the new ES6 strict simply "ES6".

Concretely, I am confused how your transition diagram is supposed to handle
"use strict";. Reading your state machine literally, since "use strict"; is
accepted by ES5, if it is accepted by ES6 (as I think we all agree it would
be), then it would leave us in state ES5&ES6. Were you two base categories
"ES6 non-strict" (or ES3) and "ES6 strict" (or ES6), then a "use strict";
would put us in your ES6 strict (or ES6) category, which is what I would
have expected.


On Thu, Jan 5, 2012 at 6:37 PM, Allen Wirfs-Brock wrote:

> Here is a possible set of rules for implicitly assigning ES5 or ES6
> semantics to a Program unit
>
> In an "ES6" implementation, all constructs that can occur in a valid
> program fit into one of these categories:
> ES6-only:  The construct is based upon syntax or static semantics rules
> that only exist in ES6.  For example, a destructuring pattern
> ES5-only:  The construct is based upon syntax that or static semantics
> rules that that are not in ES6. For example, use of a with statement t.
> ES5&ES6:  The construct has identical semantics in both ES5 and ES6.
> ES5~EAS6:  The construct has identical syntax and static semantics in both
> ES5 and ES6, but differing semantics.  For example, accessing a formal
> parameter after an assignment to the corresponding element of the
> function's arguments object.
>
> We can then use the following state machines to describes the processing
> of a Program based upon the occurrence for these feature categories.
>  Initially start in State 5&6:
>
> State 5&6
> if current construct is in ES5&ES6, process using intersection
> semantics, then goto State 5&6
> if current construct is in ES5~ES6, process using ES5 semantics then,
> goto State Compat5
> if current construct is in ES5-only, process using ES5 semantics then
> goto  State ES5
> if current construct is in ES6-only, process using ES6 semantics then
> goto State ES6
>
> State ES5
> if current construct is in ES5&ES6, process using intersection
> semantics, then goto State ES5
> if current construct is in ES5~ES6, process using ES5 semantics, then
> goto State ES5
> if current construct is in ES5-only, process using ES5 semantics then
> goto  State ES5
> if current construct is in ES6-only, terminate with Error: invalid
> combination of ES5 and ES6 features
>
> State ES6
> if current construct is in ES5&ES6, process using intersection
> semantics, then goto State ES6
> if current construct is in ES5~ES6, process using ES6 semantics, then
> goto State ES6
> if current construct is in ES5-only, terminate with Error: invalid
> combination of ES5 and ES6 features
> if current construct is in ES6-only, process using ES6 semantics then
> goto  State ES6
>
> State Compat5  (or have an analogous Compat6 state, and restart to State
> ES5 when necessary)
> if current construct is in ES5&ES6, process using intersection
> semantics, then goto State Compat5
> if current construct is in ES5~ES6, process using ES5 semantics then,
> goto State Compat5
> if current construct is in ES5-only, process using ES5 semantics then
> goto  State ES5
> if current construct is in ES6-only, abort current compilation and
> restart from beginning, starting in State ES6
>
> Basically using any ES6 features makes it an ES6 program.  Using any
> ES5-only feature makes it an ES5 program.
> Combining ES5-only and ES6 features results in an invalid program.
> If a Program can not be explicitly identified as either ES5 or ES6, it is
> treated as an ES5 program.
>
> If you want to explicitly force ES6 processing put a:
>   let ES6;
> at the top of the source file.
>
> If you want to explicitly force ES5 processing put a:
>   with (5);
> at the top of the source file
>
> Allen
>
>
>


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Allen Wirfs-Brock]

Here is a possible set of rules for implicitly assigning ES5 or ES6 semantics 
to a Program unit

In an "ES6" implementation, all constructs that can occur in a valid program 
fit into one of these categories:
ES6-only:  The construct is based upon syntax or static semantics rules that 
only exist in ES6.  For example, a destructuring pattern
ES5-only:  The construct is based upon syntax that or static semantics rules 
that that are not in ES6. For example, use of a with statement t.
ES5&ES6:  The construct has identical semantics in both ES5 and ES6.
ES5~EAS6:  The construct has identical syntax and static semantics in both ES5 
and ES6, but differing semantics.  For example, accessing a formal parameter 
after an assignment to the corresponding element of the function's arguments 
object.

We can then use the following state machines to describes the processing of a 
Program based upon the occurrence for these feature categories.  Initially 
start in State 5&6:

State 5&6
 if current construct is in ES5&ES6, process using intersection semantics, 
then goto State 5&6
 if current construct is in ES5~ES6, process using ES5 semantics then, goto 
State Compat5
 if current construct is in ES5-only, process using ES5 semantics then goto 
 State ES5
 if current construct is in ES6-only, process using ES6 semantics then goto 
State ES6

State ES5
 if current construct is in ES5&ES6, process using intersection semantics, 
then goto State ES5
 if current construct is in ES5~ES6, process using ES5 semantics, then goto 
State ES5
 if current construct is in ES5-only, process using ES5 semantics then goto 
 State ES5
 if current construct is in ES6-only, terminate with Error: invalid 
combination of ES5 and ES6 features

State ES6
 if current construct is in ES5&ES6, process using intersection semantics, 
then goto State ES6
 if current construct is in ES5~ES6, process using ES6 semantics, then goto 
State ES6
 if current construct is in ES5-only, terminate with Error: invalid 
combination of ES5 and ES6 features
 if current construct is in ES6-only, process using ES6 semantics then goto 
 State ES6

State Compat5  (or have an analogous Compat6 state, and restart to State ES5 
when necessary)
 if current construct is in ES5&ES6, process using intersection semantics, 
then goto State Compat5
 if current construct is in ES5~ES6, process using ES5 semantics then, goto 
State Compat5
 if current construct is in ES5-only, process using ES5 semantics then goto 
 State ES5
 if current construct is in ES6-only, abort current compilation and restart 
from beginning, starting in State ES6

Basically using any ES6 features makes it an ES6 program.  Using any ES5-only 
feature makes it an ES5 program.
Combining ES5-only and ES6 features results in an invalid program.
If a Program can not be explicitly identified as either ES5 or ES6, it is 
treated as an ES5 program.

If you want to explicitly force ES6 processing put a:
   let ES6;
at the top of the source file. 

If you want to explicitly force ES5 processing put a:
   with (5);
at the top of the source file

Allen


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Improving Function.prototype.bind

[Brendan Eich]

On Jan 5, 2012, at 4:47 PM, Andrea Giammarchi wrote:

> Guys, by any chance we can go back into the topic?

You'll have to polyfill Function.prototype.bind in the current world of pre-ES5 
browsers. Why not then go on to wrap it in a memoizing version that uses a 
WeakMap if available (emulated with strong keys/values array-based 
implementation if not)?

If you need this machinery, it's all doable. If we should evolve a Harmony bind 
or betterBind based on your experience and others, we can do that.

Right now the lack of memoization is not a burning issue, from what I hear. 
You've raised it, I think for the first time on es-discuss.

/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Improving Function.prototype.bind

[Andrea Giammarchi]

Guys, by any chance we can go back into the topic?
I was not thinking about changing the meaning of "this" in a function, also
Python sends explicit self context as first argument so things are slightly
different in any case 

Point is:
  - bind was one of the most needed/used Function.prototype ever, the
reason ES5 adopted it out of Prototype library
  - bind is over-enginered for 90% of use cases and it easily leads to
anti-patterns due inability to retrieve already bound functions/objects and
the need to address somewhere everything if we want to remove, as example,
a listener
  - bind, as it is, is more than fine, and developers got use to it, it
does not mean that developer could understand an Object.prototype related
method able to create and retrieve the unique function bound with that
object as context

I am seeing stuff like this everywhere

this._boundMethod = this.method.bind(this);

and in my opinion is even ugly to read ... first of all is redundant all
over the place, secondly the bound method is, in this way, easily exposed
outside.

A private scope per each instance so that bound method would be a private
variable makes even less sense ... plus bind, used with the single context
argument, is a context matter, and a single context argument, should never
be recreated unless strictly necessary but today I have still never seen
the usage for a new bound function/object used as freshly new created
object.

Nobody is using/creating two context bound on purpose so that

sameCallback.bind(sameObject)
should always be ===
sameCallback.bind(sameObject)

since the scope the callback has been created won't ever change during app
lifecycle, and accordingly it does not make sense at all to create two
different results/functions/objects

I don't want to break bind as it is, all I am proposing is to bring
Object.prototype.boundTo/asContextOf in core so that GC life is easier and
performances much fasters than whatever WeakMap or proper method, to avoid
leaks, could do.

sameObject.boundTo(sameCallback) === sameObject.boundTo(sameCallback)

is a simple method that could change 90% of frameworks out there and it's
shimmable, through my code, or others libraries.

Any thoughts on this ?
It's just needed, so if you have a better idea, since those exposed until
now do not scale or are not faster/shimmable, I'd like to listen to it.

Thanks and Best Regards
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Improving Function.prototype.bind

[Axel Rauschmayer]

> I do not believe (Axel) that the spec's Reference internal type is helpful as 
> an externally-visible part of the language in any of this.

I believe you, I know nothing about how references are actually implemented. 
Python works like this:

class Foo:
def bar():
pass

$ f = Foo()
$ f.bar
>

It has always surprised me that JavaScript preserved `this` here:
(new Date().toString)()   // (*)
But not here:
(0, new Date().toString)()

Then I found out that spec-wise, (*) is very close to Python. But if 
implementations don’t have references then it’s also impossible to keep them 
around. One could produce a bound function whenever one evaluates a reference 
to a method, but I don’t know if it’s worth the trouble (performance and 
compatibility-wise).

If you picture a method invocation obj.foo() as a single construct (and not as 
first evaluating obj.foo and then applying the () operator) then things do make 
sense – evaluating obj.foo is a different thing and simply gives you back the 
function you put there. And, thankfully, with strict mode, things fail fast if 
you forget to bind() a method.

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Improving Function.prototype.bind

[Brendan Eich]

On Jan 5, 2012, at 8:08 AM, François REMY wrote:

> >>
> >> It’s a shame that we are really close in JavaScript, with the ECMA-262 
> >> specification using references.
> >>
>  
> As things are going, things are not going to change. The strong desire to 
> avoid any behavior breakingchange between ES5 and ES6 actually makes it 
> impossible to fix a lot of issues. I’m starting to think Google may be right 
> to start over a new language,

Lots of new languages these days -- a good thing.

Starting a language is one thing. Getting adoption is another matter.


> the comitee is too conservative about ES.
>  
> But, I agree, it’s a shame.  

What *exactly* would you do here? Making methods auto-bind on extraction, with 
memoization? Please be concrete and specific.

I do not believe (Axel) that the spec's Reference internal type is helpful as 
an externally-visible part of the language in any of this.

/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Improving Function.prototype.bind

[François REMY]

I have to agree. I’m just convinced that you have to break compatibility at 
some point, or you "die". VB is a good sample. VB was great for the time he 
was introduced but it has many quirks. At some point, Microsoft broke 
compatibility, and VB.NET is born. Some developers complained, but I’m 
pretty sure nobody using VB.NET today would like to go back and make a new 
program using VB6.


I’m not an UA implementor, so I don’t want to pretend I know what should be 
done. I can’t help but repeat what I said to the IE team some time ago :


<<
While I agree with you that keeping the syntax identical allows higher 
compatibility, you should note that introducing new syntax is needed at some 
point to introduce new features "the right way" (EDIT) or to fix language 
quirks.


Web applications are coming to a point where new browsers will become a 
requirement, not due to impossibility of making the app using fallbacks but 
due to poor performance and too high maintenance and bug finding costs.


I trust Microsoft for doing the things right. ES4 was a mistake you helped 
to avoid. It was too much, too quickly. But syntax changes will come 
someday. Don't hesitate too much... or you will fragment the web scripting 
with tons of "hyper" languages like CoffeeScript. It isn't a good idea. Or 
at least it doesn't seems to me.




François



From: Axel Rauschmayer
Sent: Thursday, January 05, 2012 10:24 PM
To: François REMY
Cc: Andrea Giammarchi ; es-discuss
Subject: Re: Improving Function.prototype.bind


As things are going, things are not going to change. The strong desire to 
avoid any behavior breakingchange between ES5 and ES6 actually makes it 
impossible to fix a lot of issues. I’m starting to think Google may be right 
to start over a new language, the comitee is too conservative about ES.


Don’t forget that we do get a lot of really nice features via 
ECMAScript.next, including fixes for most quirks. The incremental approach 
does make sense and keeps everyone on board. A more radical approach has 
been tried – ECMAScript 4 – and abandoned. Furthermore, the input going into 
ES.next is diverse (E, Racket, Smalltalk, etc.). Lastly, progress is steady 
and if ES.next is finished by 2013 then that is quite impressive. Compare: 
five years between Java 6 – with few new features – and Java 7.


















--
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

















___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Improving Function.prototype.bind

[Andrea Giammarchi]

leaks, performances, as example, are the first things I have in mind when I
look at that code ( assuming I understand how WeakMap works there )

Function.prototype.bind could have been implemented via libraries ( as
Prototype did ) as well so I don't get your argument, sorry.

My point is that Function.prototype.bind is used 90% of the time with
context only, 10% with arguments, 0% as different object since nobody uses
two bound functions to the same object, arguments a part.

I am suggesting a semantic improvement Object related but of course I can
solve all missing real-nedeed things via a library ... you know what I mean?

Regards

On Thu, Jan 5, 2012 at 11:01 PM, David Bruant  wrote:

>  Hi Andrea,
>
> It seems that what you want can be implemented as a library [1] (actually
> you did it as well in your blog post). In this gist, a cache is used. In a
> nutshell, it is a '(function, object) -> boundFunction' mapping. I used 2
> levels of WeakMaps to achieve this.
>
> I don't think a native implementation could be that much more efficient
> neither in space nor time.
>
> Assuming my implementation does what you need, what would be the benefit
> of a native implementation over what I propose?
>
> David
>
> [1] https://gist.github.com/1567494
>
>
> Le 05/01/2012 14:54, Andrea Giammarchi a écrit :
>
> I have thought it may be interesting to receive some comment here too ...
> so here the short summary:
>
>  genericCallback.bind(sameObject) !== genericCallback.bind(sameObject)
>
>  quite inconvenient for listeners and leading to uncomfortable patterns (
> store the bound reference somewhere and get it back later )
>
>  plus bind, at the end of a function, where the topic is the context,
> looks more like a yoda statement
>
>  "function with context as this object"
>
>  rather than
>
>  "object as context of this function"
>
>  So, the proposal, is a simplified Object.prototype.boundTo ( or
> eventually, to avoid conflicts with bind signature
> Object.prototype.asContextOf )
> where the action is object, as context, related, and the returned function
> is one and one only
>
>  sameObject.boundTo(genericCallback) === sameObject.boundTo(
> genericCallback)
>
>  or, if you prefer
>
>  sameObject.asContextOf(genericCallback) === sameObject.asContextOf(
> genericCallback)
>
>  Here the whole post with better examples plus the proposed solution that
> would be nice to have in JS.Next
>
> http://webreflection.blogspot.com/2012/01/improving-functionprototypebind.html
>
>  Best Regards,
> Andrea Giammarchi
>
>
> ___
> es-discuss mailing 
> listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Improving Function.prototype.bind

[David Bruant]

Hi Andrea,

It seems that what you want can be implemented as a library [1]
(actually you did it as well in your blog post). In this gist, a cache
is used. In a nutshell, it is a '(function, object) -> boundFunction'
mapping. I used 2 levels of WeakMaps to achieve this.

I don't think a native implementation could be that much more efficient
neither in space nor time.

Assuming my implementation does what you need, what would be the benefit
of a native implementation over what I propose?

David

[1] https://gist.github.com/1567494


Le 05/01/2012 14:54, Andrea Giammarchi a écrit :
> I have thought it may be interesting to receive some comment here too
> ... so here the short summary:
>
> genericCallback.bind(sameObject) !== genericCallback.bind(sameObject)
>
> quite inconvenient for listeners and leading to uncomfortable patterns
> ( store the bound reference somewhere and get it back later )
>
> plus bind, at the end of a function, where the topic is the context,
> looks more like a yoda statement
>
> "function with context as this object"
>
> rather than
>
> "object as context of this function"
>
> So, the proposal, is a simplified Object.prototype.boundTo ( or
> eventually, to avoid conflicts with bind signature
> Object.prototype.asContextOf )
> where the action is object, as context, related, and the returned
> function is one and one only
>
> sameObject.boundTo(genericCallback)
> === sameObject.boundTo(genericCallback)
>
> or, if you prefer
>
> sameObject.asContextOf(genericCallback)
> === sameObject.asContextOf(genericCallback)
>
> Here the whole post with better examples plus the proposed solution
> that would be nice to have in JS.Next
> http://webreflection.blogspot.com/2012/01/improving-functionprototypebind.html
>
> Best Regards,
> Andrea Giammarchi
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Improving Function.prototype.bind

[Axel Rauschmayer]

> As things are going, things are not going to change. The strong desire to 
> avoid any behavior breakingchange between ES5 and ES6 actually makes it 
> impossible to fix a lot of issues. I’m starting to think Google may be right 
> to start over a new language, the comitee is too conservative about ES.

Don’t forget that we do get a lot of really nice features via ECMAScript.next, 
including fixes for most quirks. The incremental approach does make sense and 
keeps everyone on board. A more radical approach has been tried – ECMAScript 4 
– and abandoned. Furthermore, the input going into ES.next is diverse (E, 
Racket, Smalltalk, etc.). Lastly, progress is steady and if ES.next is finished 
by 2013 then that is quite impressive. Compare: five years between Java 6 – 
with few new features – and Java 7.

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

On Jan 5, 2012, at 8:30 AM, Axel Rauschmayer wrote:

> On Jan 5, 2012, at 1:56 , Brendan Eich wrote:
> 
>> Better to dispense with modes or ordered versions altogether, which is the 
>> key idea of the proposal.
> 
> 
> So, simplified, the story is:
> 
> - ES6 is a superset of ES5.strict.

That's always been promised.


> - ES{3,5}.non-strict is neither a subset nor a superset of ES6, it has to be 
> handled differently.
> 
> If these modes (strict versus non-strict) exist, then I would want a per-file 
> marker for strict code:
> - "use strict";

This doesn't mean Harmony, though. Not now, in ES5 implementations -- it means 
only ES5-strict. And not in dowrev impls, where it means nothing (and semantics 
differ at runtime).


> - use strict;

This is a good idea but it was not proposed by Dave to mean Harmony opt-in. 
Rather, |use module;| was, as a way to avoid bracing and indenting a top level 
hunk of code in an anonymous module {...} declaration.


> - module {
> 
> 
> Compared to languages such as Java, JavaScript additionally faces the 
> challenge that a developer can’t control what language version is implemented 
> by the browser. How will that be handled? Sketching a solution would provide 
> a more complete picture of how to migrate to ES6.

APIs can be object-detected. New syntax requires autoconf-style eval/Function 
tests. All doable, nothing mysterious, some try/catch pain required.

I rather expect a boot-loader script will use more coarse-grained means of 
deciding what to fetch. We had proposed a way to reflect on the maximum 
supported version (__ECMASCRIPT_VERSION__, IIRC) but that was unsatisfying. 
More to do here.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

On Jan 5, 2012, at 11:10 AM, Brendan Eich wrote:

>> That precluded a number of highly undesirable
>> combinations, e.g. extended mode nested into a "with" statement.
> 
> You can "use strict"; in a with statement's body block.

Sorry to be unclear, I meant examples such as this:

js> with ({p:1}) { print(function () {"use strict"; return p;}()); }
1

The strict function expression still has to cope with the nasty object scope 
environment on its outside.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

On Jan 5, 2012, at 9:30 AM, Allen Wirfs-Brock wrote:

> A slightly different approach to this might be to say that the use of any new 
> syntax implies that the immediately surrounding function or program is in 
> strict mode.

I'm favoring program currently, even if the new syntax is used in just one (of 
N) functions declared or expressed in the program. We could be narrow and 
impute Harmony opt-in only to the nearest containing function (or failing that, 
program). That might help incremental migration, indeed, and it seems a more 
locally "reasonable" rule.

But it may be that developers would benefit more from 
in-for-a-penny-in-for-a-pound. Hard to say without user testing.


>  In other words, the default is strict mode unless the code exclusively uses 
> ES5 syntactic constructs.

Right, but we need to settle on the unit or scale of "the code".

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Brendan Eich]

On Jan 5, 2012, at 6:31 AM, Andreas Rossberg wrote:

>>> explicit opt-in)
>> 
>> No -- "use strict"; the string literal expression-statement is meaningless 
>> pre-ES5, ES5-strict in ES5, and redundant in Harmony code.
> 
> You said earlier that we best rely on the meta tag for the script
> toplevel, which isn't exactly a No. ;)

Trying to avoid scope creep. Also not dismissing RFC4329 ;version=6 parameter 
setting -- that works to hide new code from old browsers (I believe back to IE8 
-- perhaps not the geriatric browsers).


>> Now what do you say?
> 
> Sorry, I still think that a growing set of subtle implicit rules for
> activating subtle semantic changes

Not changes, new semantics for new syntax. The fingers of fate may allow 
completion reform (Mark and I think so). The interactions are not that hard, 
and making a mode-wall doesn't avoid solving all of them -- you still may have 
runtime (heap-based) interactions between old and new modes.

We did JS1.7 this way, BTW. You had to opt in to get 'let' and 'yield', but 
that was for the compiler. We did not hold back other features, and there were 
no runtime (post-compile) version checks:

brendan-eichs-computer-3:src.old brendaneich$ grep VERSION_1_7 *.c
jsapi.c:{JSVERSION_1_7, "1.7"},
jsparse.c:   || (JSVERSION_NUMBER(cx) == JSVERSION_1_7 &&
jsparse.c:   ((JSVERSION_NUMBER(cx) == JSVERSION_1_7 &&
jsparse.c:if (JSVERSION_NUMBER(cx) == JSVERSION_1_7) {
jsparse.c:if (JSVERSION_NUMBER(cx) == JSVERSION_1_7) {

(jsapi.c is just a string <-> enumerator mapping table; jsparse.c shows the 
compiler checks.)


> on a fine-grained level is far more
> confusing (and error-prone!) than helpful. In all sorts of ways.

Our experience was that adding new features to the default version where there 
was no backward incompatibility was not confusing. We've been doing this since 
2006. Not to say all the particulars are right, or that we anticipated all the 
combinations of ES5-strict and Harmony, of course! But I think you protest too 
much without evidence.


> I'm also concerned about the 3 and a half language modes that might
> result. With Dave's original proposal at least, the only opt-in was on
> module level.

Dave mentioned generators, IIRC. We were thinking of classes too (talked about 
it privately).


> That precluded a number of highly undesirable
> combinations, e.g. extended mode nested into a "with" statement.

You can "use strict"; in a with statement's body block. But see below, I agree 
the opt in has to be "chunky", and is in the (not perfectly clear, complete, 
etc.) proposal for "ES6 doesn't need [version] opt-in".


> Allen
> gave a couple of good examples we also ran into when trying to
> implement block scoping liberally in V8 -- in the end, we concluded
> that it doesn't make sense to allow opting into extended mode locally.

Yes, this is one place where during the ES4 period, we made 'let' at top level 
of program and function bodies equate to 'var', which is no good (arguments 
aliasing, for one). But lesson learned.

The idea is to opt in at least the enclosing function, if not the enclosing 
Program (non-terminal, so 

Re: ES6 doesn't need opt-in

[Allen Wirfs-Brock]

On Jan 4, 2012, at 11:38 PM, Mark S. Miller wrote:

> In your suggestion, when an occurrence of destructuring (or any other new 
> syntax) is seen, what unit of code is then opting in to strict? Would it be 
> the nearest enclosing function, module, class, generator, or Program? I think 
> I'm warming to the idea.
> 
> I think having the opt-in unit be the destructuring pattern and everything 
> recursively contained within it would be a bad idea. In this regard, 
> destructuring is a different category of opt-in by new syntax than is module, 
> class, and generator.

This first came up in the context of formal parameters that use destructuring 
(or default value initializers, or rest).  In that case, the idea was that this 
would imply that the function with those parameters is a "strict" function.

Whether  the use of destructuring (or rest/spread) in declarations or 
expressions within the body of the function also implies a "strict" function is 
potentially a separate issue. However, I  think we need to keep things as 
simple and consistent as possible so on that basis perhaps they should also 
imply a strict function.  In neither case, were we thinking of restricting the 
strictness to just the destructuring pattern itself.

A slightly different approach to this might be to say that the use of any new 
syntax implies that the immediately surrounding function or program is in 
strict mode.  In other words, the default is strict mode unless the code 
exclusively uses ES5 syntactic constructs.

Allen



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Improving Function.prototype.bind

[Andrea Giammarchi]

all the time since I widely use private methods and I reuse them per each
created instance of a specific "class"

The boundTo() approach would make the method still private, immutable out
there, and reusable per each instance/object I need.

// stupid useless example ... just as concept
var Counter = (function () {
  // private
  function increase() {
this.age++;
  }

  function Counter() {
// none out there should be able to retrieve the bound function
document.addEventListener("click", this.boundTo(increase), false);
  };
  Counter.prototype.age = 0;
  Counter.prototype.destroy = function () {
// so that only this class scope can control things and nobody else
document.removeEventListener("click", this.boundTo(increase), false);
  };
  return Counter;
}());

Last, but not least, I do duck typing and I often borrow methods around for
smaller common tasks

Best Regards,
Andrea Giammarchi



On Thu, Jan 5, 2012 at 5:11 PM, Axel Rauschmayer  wrote:

> that would not solve much 'cause you can bind a function to a single
> object and no more.
>
>
> Isn’t that the most frequent use case? Do you have examples where you bind
> the same function to several objects?
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
>
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
>
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Axel Rauschmayer]

On Jan 5, 2012, at 1:56 , Brendan Eich wrote:

> Better to dispense with modes or ordered versions altogether, which is the 
> key idea of the proposal.


So, simplified, the story is:

- ES6 is a superset of ES5.strict.
- Therefore, as soon as we have ES6, ES5.strict code bases automatically become 
ES6 code bases.
- ES{3,5}.non-strict is neither a subset nor a superset of ES6, it has to be 
handled differently.

If these modes (strict versus non-strict) exist, then I would want a per-file 
marker for strict code:
- "use strict";
- use strict;
- module {


Compared to languages such as Java, JavaScript additionally faces the challenge 
that a developer can’t control what language version is implemented by the 
browser. How will that be handled? Sketching a solution would provide a more 
complete picture of how to migrate to ES6.

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Improving Function.prototype.bind

[Axel Rauschmayer]

> that would not solve much 'cause you can bind a function to a single object 
> and no more.

Isn’t that the most frequent use case? Do you have examples where you bind the 
same function to several objects?

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Improving Function.prototype.bind

[François REMY]

>>
>> It’s a shame that we are really close in JavaScript, with the ECMA-262 
>> specification using references.
>>
As things are going, things are not going to change. The strong desire to avoid 
any behavior breakingchange between ES5 and ES6 actually makes it impossible to 
fix a lot of issues. I’m starting to think Google may be right to start over a 
new language, the comitee is too conservative about ES.
But, I agree, it’s a shame.  ___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Improving Function.prototype.bind

[Andrea Giammarchi]

that would not solve much 'cause you can bind a function to a single object
and no more.

My proposal is object related so that eventually, even if you forget to
explicitly drop already bound callbacks, those stacks should be GCed
automagically and memory speaking it should be safe.

@Jake I find that a bit too much universal approach, I mean ... it does not
real scale and it may be redundant in many cases, as example when you
simply have the right context in a function and you call other via this
where the bound one would not be necessary.

Object.prototype.bindAll could be, in any case, a nice addiction, except we
need proxies for runtime added/borrowed methods when/if necessary otherwise
the risk is double bound without reasons and at that time the problem about
listeners would still be there.

regards

On Thu, Jan 5, 2012 at 4:52 PM, Axel Rauschmayer  wrote:

> On Jan 5, 2012, at 14:54 , Andrea Giammarchi wrote:
>
> Here the whole post with better examples plus the proposed solution that
> would be nice to have in JS.Next
>
> http://webreflection.blogspot.com/2012/01/improving-functionprototypebind.html
>
>
> I don’t use bound() and function expressions very often (I prefer that =
> this for most use cases).
>
> However, the register/unregister pitfall is indeed real. How about the
> following solution?
>
> Function.prototype.attachTo = function (obj) {
> this.bound = this.bind(obj);
> return this;
> }
>
> var obj = {
> mymethod: function () {
> // ...
> }.attachTo(obj)
> }
>
> generic.addEventListener("stuff", obj.mymethod.bound, false);
> generic.removeEventListener("stuff", obj.mymethod.bound, false);
>
> Python always binds methods that you access via obj.mymethod. Multiple
> accesses are equal (which I think is carried over to data structures), but
> not the same reference.
>
> It’s a shame that we are really close in JavaScript, with the ECMA-262
> specification using references.
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
>
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
>
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Improving Function.prototype.bind

[Axel Rauschmayer]

On Jan 5, 2012, at 14:54 , Andrea Giammarchi wrote:

> Here the whole post with better examples plus the proposed solution that 
> would be nice to have in JS.Next
> http://webreflection.blogspot.com/2012/01/improving-functionprototypebind.html


I don’t use bound() and function expressions very often (I prefer that = this 
for most use cases).

However, the register/unregister pitfall is indeed real. How about the 
following solution?

Function.prototype.attachTo = function (obj) {
this.bound = this.bind(obj);
return this;
}

var obj = {
mymethod: function () {
// ...
}.attachTo(obj)
}

generic.addEventListener("stuff", obj.mymethod.bound, false);
generic.removeEventListener("stuff", obj.mymethod.bound, false);

Python always binds methods that you access via obj.mymethod. Multiple accesses 
are equal (which I think is carried over to data structures), but not the same 
reference.

It’s a shame that we are really close in JavaScript, with the ECMA-262 
specification using references.

-- 
Dr. Axel Rauschmayer
a...@rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Andreas Rossberg]

On 4 January 2012 21:52, Brendan Eich  wrote:
> On Jan 4, 2012, at 4:23 AM, Andreas Rossberg wrote:
>
>> - Despite the superficial "fewer modes" mantra, it actually doesn't
>> make the language simpler, but more complicated: instead of defining
>> the semantics for Harmony features only for strict-mode programs, we
>> now have to define many features for both modes (and mixed uses of
>> both modes). I.e., there are more syntactic and semantic combinations
>> to worry about.
>
> Yes, this is a trade-off. It probably helps developers migrate, provided they 
> choose sane combinations. For example, Allen (private correspondence) 
> wondered if a function using the arguments object is evolved to have 
> destructuring parameters:
>
>  function f({a,b}, c) { arguments[0] = {a:3,b:4}; return [a, b] }
>  f({a:1,b:2}, 3);
>
> I say anyone wanting deep aliasing (f returns [3, 4]) should suffer 
> disappointment. I doubt developers want such deep aliasing, and no 
> implementor does.

Whoa, yeah, please let's not go there.


>> - All this together (new features in old mode,
>
> Nope. ;-)
>
>
>> implicit opt-in,
>
> Yup.
>
>
>> explicit opt-in)
>
> No -- "use strict"; the string literal expression-statement is meaningless 
> pre-ES5, ES5-strict in ES5, and redundant in Harmony code.

You said earlier that we best rely on the meta tag for the script
toplevel, which isn't exactly a No. ;)

> Now what do you say?

Sorry, I still think that a growing set of subtle implicit rules for
activating subtle semantic changes on a fine-grained level is far more
confusing (and error-prone!) than helpful. In all sorts of ways.

I'm also concerned about the 3 and a half language modes that might
result. With Dave's original proposal at least, the only opt-in was on
module level. That precluded a number of highly undesirable
combinations, e.g. extended mode nested into a "with" statement. Allen
gave a couple of good examples we also ran into when trying to
implement block scoping liberally in V8 -- in the end, we concluded
that it doesn't make sense to allow opting into extended mode locally.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Andreas Rossberg]

On 4 January 2012 21:30, Brendan Eich  wrote:
>> In any case, even if we allow more features in classic mode
>
> Don't think of modes and you'll be grooving with the new proposal better ;-).

Well, I'd say "syntactic context" is just a euphemism. Or maybe the
other way round...

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Andreas Rossberg]

On 4 January 2012 21:27, Brendan Eich  wrote:
> On Jan 4, 2012, at 4:12 AM, Andreas Rossberg wrote:
>>>
>>> Your (3) seemed to say "use module" was something distinct from (and also
>>> implicit in, so a part but not the whole of what is declared by) module
>>> declaration syntax. It's not -- as proposed, it's an alternative to explicit
>>> anonymous module{...} bracketing syntax that translates the block or body
>>> enclosing the pragma to an anonymous module.
>>
>> Yes, I understand that. My point was that you can reformulate all
>> that, for (almost) equivalent effect, by saying that "use module" is
>> _not_ a module definition, but basically the same mode pragma as
>> before,
>
> Just to be clear: you mean |use version 6;| here by "mode pragma as before"?

Yes.

>> The only difference I can see with this description is its effect on
>> the semantics of multi-part scripts.
>
> Dave's proposal has
>
>   
>     window.foo = "hi";
>   
>   
>     use module;
>     alert(foo);
>   
>
> desugar to
>
>   
>     window.foo = "hi";
>   
>   
>     module {
>       alert(foo);   // no early error, runs and alerts "hi"
>     }
>   
>
> which is not the same as what we were thinking of with "no global object as
> top scope" enabled by a version pragma:
>
>   
>     window.foo = "hi";
>   
>   
>     use version 6;
>     alert(foo);     // early error here!
>   

Right. That's (part of) what I was alluding to with my above remark. ;)

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Improving Function.prototype.bind

[Andrea Giammarchi]

I have thought it may be interesting to receive some comment here too ...
so here the short summary:

genericCallback.bind(sameObject) !== genericCallback.bind(sameObject)

quite inconvenient for listeners and leading to uncomfortable patterns (
store the bound reference somewhere and get it back later )

plus bind, at the end of a function, where the topic is the context, looks
more like a yoda statement

"function with context as this object"

rather than

"object as context of this function"

So, the proposal, is a simplified Object.prototype.boundTo ( or eventually,
to avoid conflicts with bind signature Object.prototype.asContextOf )
where the action is object, as context, related, and the returned function
is one and one only

sameObject.boundTo(genericCallback) === sameObject.boundTo(genericCallback)

or, if you prefer

sameObject.asContextOf(genericCallback) === sameObject.asContextOf(
genericCallback)

Here the whole post with better examples plus the proposed solution that
would be nice to have in JS.Next
http://webreflection.blogspot.com/2012/01/improving-functionprototypebind.html

Best Regards,
Andrea Giammarchi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 doesn't need opt-in

[Claus Reinke]

Considering all that, I can't help feeling that having a separate mode
is cleaner, simpler, and easier to use. I think it also has more
potential for providing a robust foundation for future evolution of
the language.


This last point -language evolution- is something that Haskellers
have quite a bit of experience with, and I've tried to raise the issue
of feature-based language versioning here earlier [1,2].

In Haskell's beginning, there was the single language standard, and
every implementation had a single flag for enabling all of its additional
or experimental features (beyond the standard). But implementations
come and go, and even the de-facto standard of most-widely-used
implementation has changed over time. Even when several
implementations agreed on a feature, they might disagree on some
details (eg, a proven safe but restrictive variant versus a possibly
unsafe but pragmatically better version). And the language
committees have been notoriously slow in adopting experimental
features into the language standard.

So the situation became untenable, and the solution was feature-based
language versioning (based on pragmas), in addition to named standards:

By default, code is interpreted according to the most recent language
standard but, for stability, code can explicitly opt into a specific version
of the standard. Up to here, that is similar to Javascript, only that the
version can be specified in code pragmas as well.

On top of this default, language *extensions* can be selected individually,
via pragmas. It is then up to the implementation to recognize whether
or not the selected set of language extensions is supported. As in JS,
language extensions tend to have recognizable syntax, too, so
implementations can also warn intelligently about attempts to use
features that have not been selected (or about conflicts that arise
because of features that have been selected, such as stolen syntax).

Useful language extensions can be adopted by other implementations
(at which point they need to be specified, not just implemented), and
later moved into one of the next language standards. Agreeing on the
next language standard becomes more of gather-successful-features
than redesign-everything-from-scratch, with shorter language update
cycles as well. A feature missing a language update deadline becomes
less of an issue, as it is still available as an extension. Features that do
not work out in practice are easier to remove, as they have their own
pragma (not mixed into a numeric language version).

In the current phase of JS evolution, with an evolving new standard
and partial implementations of new features, it would be especially
helpful to identify which features a piece of code depends on and
which features a given implementation supports. Being able to opt
in to new features individually also puts a bound on upgrade work
(e.g. opt into let, but not yield, or vice-versa), and helps to ensure
that coders are aware of changes (if I opt into let, I expect let to be
special; if I opt into ES.next because I want yield, I might be surprised
by changes to let and scope and typeof and ..).

Just a thought..
Claus

[1] Should ES begin to standardise pragmas?
   https://mail.mozilla.org/pipermail/es-discuss/2011-April/013791.html
[2] feature-based and compartment-based language versioning
   https://mail.mozilla.org/pipermail/es-discuss/2011-July/015755.html


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Boolean shortcuts

[Herby Vojčík]

Yeah, it looks. And it needs no special case in used in var.

-Pôvodná správa- 
From: Nadav Shesek

Sent: Thursday, January 05, 2012 2:00 PM
To: Herby Vojčík
Cc: mikesam...@gmail.com ; es-discuss@mozilla.org
Subject: Re: Boolean shortcuts


There was a suggestion for CoffeeScript, which got implemented by Coco, for 
`{+enumerable, -configurable, +writable}` syntax that does that. It has the 
same potential ambiguity, but looks better IMO.



On Thu, Jan 5, 2012 at 9:29 AM, Herby Vojčík  wrote:
Hello,

...

So I would make the proposal alive again, but the thread got cluttered. :-/

Thanks again for showing me not to panic,


Herby

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Boolean shortcuts

[Nadav Shesek]

There was a suggestion for CoffeeScript, which got implemented by
Coco,
for `{+enumerable, -configurable, +writable}` syntax that does that. It has
the same potential ambiguity, but looks better IMO.

On Thu, Jan 5, 2012 at 9:29 AM, Herby Vojčík  wrote:

> Hello,
>
> sorry that I did not get it from the beginning.
> You are right.
> I am really concerned about use of boolean shortcuts in the context of
> object initializer.
> But François's examples scared me.
> Especially the impossibility of `{ !window }.callFunc();` kind of
> statements.
> But in such case, early error should tell me I am in the wrong way and
> people are accepting that this kind of construct need parentheses to
> disambiguate (especially for the ({}).foo case).
>
> So I would make the proposal alive again, but the thread got cluttered. :-/
>
> Thanks again for showing me not to panic,
>
>
> Herby
>
> -Pôvodná správa- From: Mike Samuel
> Sent: Wednesday, January 04, 2012 6:29 PM
> To: Herby Vojčík
> Cc: François REMY ; es-discuss@mozilla.org
> Subject: Re: Boolean shortcuts
>
> 2012/1/4 Herby Vojčík :
>
>> Curse that eval-uation of a code block! This prevents not only this, but a
>> lot of more possible enhancements/reforms!
>>
>
> I don't see the problem.  You are proposing a change to the
> ObjectInitialiser production.  Francois's example just demonstrates
> something we already know -- that there exist strings that will parse
> as an ObjectInitialiser when you start in the Expression production
> but parse as a Block when you start in the Program production.
>
> eval('{ !window }') is and would remain a block, and eval('({ !window
> })') with your proposal would be unambiguously an object initialiser,
> and is a SyntaxError in ES5.
> __**_
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss
>



-- 
Nadav IvgiSoftware
Developer+972-50-3650394
http://www.shesek.info/GMT +2
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss