I would be more than happy to go on with libraries first approach as long
as we don't have to wait 6 years before a needed feature is going to be
considered.
I have also raised the problem because it is in my opinion underestimated
but mainly because I would like to avoid the fragmentation of
Le 09/01/2012 06:29, Brendan Eich a écrit :
On Jan 8, 2012, at 7:20 PM, John J Barton wrote:
On Sun, Jan 8, 2012 at 3:35 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Firebug uses a library bind a lot, and we continually struggled
with the memoization
Le 08/01/2012 19:47, John J Barton a écrit :
(...)
window.addEventListener('load', boundOnLoad, false);
...
window.removeEventListener('load', boundOnLoad, false);
The JS method 1) must be bound to the correct object 2) be
reference-able for the removeEventListener.
This combination
indeed ... inline functions are problem number 2, anonymous or not, unless
the removeEventListener is not performed inside the function itself so that
at least the function name could be reused while if anonymous and use
strict is in place there's no way to know which function is it.
However, two
On Jan 9, 2012, at 12:29 AM, David Bruant wrote:
Le 09/01/2012 06:29, Brendan Eich a écrit :
On Jan 8, 2012, at 7:20 PM, John J Barton wrote:
On Sun, Jan 8, 2012 at 3:35 PM, Brendan Eich bren...@mozilla.com wrote:
Firebug uses a library bind a lot, and we continually struggled with the
just to make it more concrete for those interested:
http://webreflection.blogspot.com/2012/01/introducing-objecthandler.html
IDL Like description and code ... to me this is a much faster/easier/better
solution than Function#bind ... unshimmable for IE 9 but ... you know,
some wrapper could do
On Thu, Jan 5, 2012 at 11:47 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
...
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 bren...@mozilla.com wrote:
On Jan 5, 2012, at 4:47 PM, Andrea Giammarchi wrote:
Right
On Jan 8, 2012, at 10:47 AM, John J Barton wrote:
That is why our code is now littered with:
BTW, which our code?
baz.boundOnLoad = baz.onLoad.bind(baz); // bah, JS voodoo
In my code I now have a function _bindListeners() called from initialize()
where I list all of this goop. The
On Sun, Jan 8, 2012 at 11:39 AM, Brendan Eich bren...@mozilla.com wrote:
On Jan 8, 2012, at 10:47 AM, John J Barton wrote:
That is why our code is now littered with:
BTW, which our code?
Mine, Andrea's, Hewitt's Firebug at least. I believe we have already
lamented our limited ability to
On Jan 8, 2012, at 12:29 PM, John J Barton wrote:
On Sun, Jan 8, 2012 at 11:39 AM, Brendan Eich bren...@mozilla.com wrote:
On Jan 8, 2012, at 10:47 AM, John J Barton wrote:
That is why our code is now littered with:
BTW, which our code?
Mine, Andrea's, Hewitt's Firebug at least.
On Sun, Jan 8, 2012 at 3:35 PM, Brendan Eich bren...@mozilla.com wrote:
[...]
That's not totally clear now in light of Mark's emulated WeakMap not
leaking in practice.
[...]
That's a much stronger claim than I would be willing to make. My emulated
WeakMaps leak much less that one would
Sorry about the format mangling. Resending with simpler formatting which
hopefully won't get mangled in transmission.
-- Forwarded message --
From: Mark S. Miller erig...@google.com
Date: Sun, Jan 8, 2012 at 5:05 PM
Subject: Re: Improving Function.prototype.bind
To: Brendan Eich
On Sun, Jan 8, 2012 at 3:35 PM, Brendan Eich bren...@mozilla.com wrote:
Anyway, this is all water under the bridge. What about the future? My
position is still do the library work and popularize. Even if you really
need a fast-track ES.next solution, the library work must come first.
I'm
Just a bit of back story on Function#bind because I think it's good to know.
Prototype's Function#bind was based on the 2004 post Object-Oriented
Event Listening through Partial Application in JavaScript by Daniel
Brockman:
same thing this does
var bound = Object.bind(Object);
bound.foo = capabilityBobShouldntGet; // who does this ?
var HAH = bound.foo;
... so I am missing your point I guess ... but my proposal wants to return
always same object for 99.9% of usage out there ...
On Fri, Jan 6, 2012 at 8:55 AM,
as
keys. I don't know to what extent it would be that much better.
as example, are the first things I have in mind when I look at that
code ( assuming I understand how WeakMap works there )
(...)
My point is that Function.prototype.bind is used 90% of the time with
context only, 10
]]
- return the newly created boundFunction
Would that be possible?
François
-Message d'origine-
From: Brendan Eich
Sent: Friday, January 06, 2012 2:22 AM
To: Andrea Giammarchi
Cc: Axel Rauschmayer ; François REMY ; es-discuss
Subject: Re: Improving Function.prototype.bind
On Jan 5, 2012
My proposal could break existing code so it’s probably not worth a shot in ES6.
Maybe in ES7, then.
From: Brendan Eich
Sent: Friday, January 06, 2012 12:52 AM
To: François REMY
Cc: Axel Rauschmayer ; Andrea Giammarchi ; es-discuss
Subject: Re: Improving Function.prototype.bind
What *exactly
Le 06/01/2012 06:03, Mark S. Miller a écrit :
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
-discuss
Subject: Re: Improving Function.prototype.bind
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
the 2
references as keys. I don't know to what extent it would be that
much better.
as example, are the first things I have in mind when I look at
that code ( assuming I understand how WeakMap works there )
(...)
My point is that Function.prototype.bind is used 90
On Fri, Jan 6, 2012 at 10:50 AM, David Bruant bruan...@gmail.com wrote:
Your proposal won't be implemented in older browsers. Actually, it is very
likely that your proposal would be implemented in browsers that would
already have weak maps.
Under these conditions. What is the benefit of a
Le 06/01/2012 11:20, Andrea Giammarchi a écrit :
On Fri, Jan 6, 2012 at 10:50 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Your proposal won't be implemented in older browsers. Actually, it
is very likely that your proposal would be implemented in browsers
it doesn't ... as soon as you release the reference to o no leaks persists
but of course until you keep o on hold those unique callbacks cannot be
released ... but this would be true with WeakMap too, isn't it?
In any case, boundTo is suitable for listeners and the whole point is to do
not hold
Le 06/01/2012 12:23, Andrea Giammarchi a écrit :
it doesn't ... as soon as you release the reference to o no leaks
persists but of course until you keep o on hold those unique callbacks
cannot be released ...
If you're telling me that keeping only one of the object or the function
alive but
unreachable without reference count? do you have an example different from
a private scope object that is reachable from that scope so I would not
call it unreachable?
In any case I understand your leaks point and if WeakMap solves this, but I
strongly believe no shim will be able to emulate this
Le 06/01/2012 12:51, Andrea Giammarchi a écrit :
unreachable without reference count? do you have an example different
from a private scope object that is reachable from that scope so I
would not call it unreachable?
I'm not sure I understand your question.
In IE6 (7? 8?), written naively,
there is no security issue ... it's meant like that plus what Mark did not
think about, is that if I use
(function () {
function callback() {}
var object = {};
window.addEventListener(no way, object.boundTo(callback), false);
// later on
window.removeEventListener(no way,
Le 06/01/2012 16:54, Andrea Giammarchi a écrit :
there is no security issue ... it's meant like that plus what Mark did
not think about, is that if I use
(function () {
function callback() {}
var object = {};
window.addEventListener(no way, object.boundTo(callback), false);
//
On Fri, Jan 6, 2012 at 8:31 AM, David Bruant bruan...@gmail.com wrote:
Le 06/01/2012 06:03, Mark S. Miller a écrit :
Such a built in memoization, whether by boundTo or this enhancement to
bind itself, creates a fatal ambient communications channel.
// initSES initialization, freezing
Alice wouldn't normally be able to communicate 'bound' to Bob, and thus Bob
wouldn't be able to read Alice's 'bound.foo'. The issue is much like ES3's
mistake of evaluation a RegExp literal once to a RegExp object -- everyone
executing the same code could now communicate, even if all accessible
-Message d'origine- From: Brendan Eich
Sent: Friday, January 06, 2012 2:22 AM
To: Andrea Giammarchi
Cc: Axel Rauschmayer ; François REMY ; es-discuss
Subject: Re: Improving Function.prototype.bind
On Jan 5, 2012, at 4:47 PM, Andrea Giammarchi wrote:
Guys, by any chance we can go back
Le 06/01/2012 17:43, Mark S. Miller a écrit :
On Fri, Jan 6, 2012 at 8:31 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 06/01/2012 06:03, Mark S. Miller a écrit :
Such a built in memoization, whether by boundTo or this
enhancement to bind itself,
On Fri, Jan 6, 2012 at 1:31 AM, David Bruant bruan...@gmail.com wrote:
[...]
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.
Are you talking
, right? Or am I missing something?
From: Mark S. Miller
Sent: Friday, January 06, 2012 5:53 PM
To: François REMY
Cc: Brendan Eich ; Andrea Giammarchi ; es-discuss
Subject: Re: Improving Function.prototype.bind
On Fri, Jan 6, 2012 at 1:29 AM, François REMY fremycompany_...@yahoo.fr wrote
. Miller erig...@google.com
*Sent:* Friday, January 06, 2012 5:53 PM
*To:* François REMY fremycompany_...@yahoo.fr
*Cc:* Brendan Eich bren...@mozilla.com ; Andrea
Giammarchiandrea.giammar...@gmail.com;
es-discuss es-discuss@mozilla.org
*Subject:* Re: Improving Function.prototype.bind
On Fri, Jan 6
that whole variable can be redefined or used as communication channel ... I
really don't understand what is the problem.
The returned bound once object could be frozen without problems but if the
function is private with the gist I have posted:
1. you cannot redefine Object.prototype at all
2.
On Fri, Jan 6, 2012 at 9:27 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
that whole variable can be redefined or used as communication channel ...
I really don't understand what is the problem.
The variable Object? No, in SES that's unassignable. As layered on ES5,
we enforce
On Fri, Jan 6, 2012 at 6:56 PM, Mark S. Miller erig...@google.com wrote:
On Fri, Jan 6, 2012 at 9:27 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
that whole variable can be redefined or used as communication channel ...
I really don't understand what is the problem.
The
Maybe interesting for others too, since we talked about WeakMap a lot in
this thread:
My essential polyfill here:
https://gist.github.com/1571878
100% code coverage here:
https://gist.github.com/1571887
Best Regards,
Andrea Giammarchi
___
On Fri, Jan 6, 2012 at 10:02 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
[...]
1. everyone can WeakMap = function () {}; anywhere
Again, no they can't because all whitelisted global variables are
unassignable.
it's a var WeakMap in the global scope ... still talking about
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
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
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
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
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
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
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
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
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
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
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
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
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
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
to this WeakMap, in
which case they could already communicate anyway.
On Thu, Jan 5, 2012 at 5:22 PM, Brendan Eich bren...@mozilla.com 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
, 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
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
var f = function() { return this; }
var g = f.bind(???);
g.apply({ foo: bar }).foo // expect bar
Function.prototype.bind set's the thisArg to a certain value. Is there any
way to leave it flexible to be overwritten using `.call` and `.apply` later
on?
Is there any ES:Harmony/strawman proposal
On Wed, Sep 7, 2011 at 2:46 PM, Jake Verbaten rayn...@gmail.com wrote:
var f = function() { return this; }
var g = f.bind(???);
g.apply({ foo: bar }).foo // expect bar
Function.prototype.bind set's the thisArg to a certain value. Is there any
way to leave it flexible to be overwritten
On Wed, Sep 7, 2011 at 2:52 PM, Mark S. Miller erig...@google.com wrote:
If there is not I propose using `undefined` to tell Function.prototype.bind
to leave thisArg flexible.
We cannot use 'undefined' for this, as we already use f.bind(undefined) in
order to ensure that f's
.
But this means libraries like MooTools automatically break the JavaScript
standard, as now Function.prototype.bind gets overridden with an
incompatible version. And it also is too late for MooTools to change that
now, as such a change would break all depending code at once.
Libraries that extend
On Sat, May 1, 2010 at 3:16 AM, Jürg Lehni li...@scratchdisk.com wrote:
Also, could you show me a real world use case of the argument concatenation
feature found in hitch and bind? I am not working with Prototype nor Dojo,
but so far I have not come to face a situation where this would have
On Apr 30, 2010, at 10:28 PM, Garrett Smith wrote:
It could be that we missed a chance to add Function.bind(callable,
thisObj,
argsArray). Adding such a static method might have provided the
desired
common utility usable without conflicts by libraries. We may yet
add such a
Function.bind.
to it when calling. I actually prefer
this passing of arguments in an array over the standardised bind, for
reasons explained in my previous email.
But this means libraries like MooTools automatically break the JavaScript
standard, as now Function.prototype.bind gets overridden
But would that really be a problem?
Function as an instance could have a different definition of bind that
overrides the one from prototype.
I can see how this is maybe not most elegant approach, but would you ever need
to bind a constructor to another object?
Jürg
On 1 May 2010, at 07:07,
On 1 May 2010, at 01:50, Brendan Eich wrote:
MooTools takes an array of actual arguments to bind, while the others take
trailing positional actual params, I see. My point was that however they are
passed, these values are bound to the leading arguments supplied when the
bound method is
On May 1, 2010, at 3:28 AM, Jürg Lehni wrote:
On 1 May 2010, at 01:50, Brendan Eich wrote:
MooTools takes an array of actual arguments to bind, while the
others take trailing positional actual params, I see. My point was
that however they are passed, these values are bound to the leading
On Sat, May 1, 2010 at 7:13 AM, Brendan Eich bren...@mozilla.com wrote:
On May 1, 2010, at 3:28 AM, Jürg Lehni wrote:
On 1 May 2010, at 01:50, Brendan Eich wrote:
[...]
Odd, that is neither fish nor fowl. Does any other library have such a bind?
Anyway, Moo was not around when TC39 was
On Fri, Apr 30, 2010 at 11:07 PM, Brendan Eich bren...@mozilla.com wrote:
On Apr 30, 2010, at 10:28 PM, Garrett Smith wrote:
It could be that we missed a chance to add Function.bind(callable,
thisObj,
argsArray). Adding such a static method might have provided the desired
common utility
On Sat, May 1, 2010 at 10:13 AM, Brendan Eich bren...@mozilla.com wrote:
On May 1, 2010, at 3:28 AM, Jürg Lehni wrote:
On 1 May 2010, at 01:50, Brendan Eich wrote:
MooTools takes an array of actual arguments to bind, while the others take
trailing positional actual params, I see. My point
After having used my own version of an implementation of
Function.prototype.bind for about 4 years now I recently became aware of the
one that appears to now be standardised in ES5.
The following page suggests its definition stems from the Prototype.js library:
http://wiki.ecmascript.org
On Apr 30, 2010, at 6:32 AM, Jürg Lehni wrote:
After having used my own version of an implementation of
Function.prototype.bind for about 4 years now I recently became
aware of the one that appears to now be standardised in ES5.
The following page suggests its definition stems from
libraries like MooTools automatically break the JavaScript
standard, as now Function.prototype.bind gets overridden with an incompatible
version. And it also is too late for MooTools to change that now, as such a
change would break all depending code at once.
This then raises other interesting
MooTools automatically break the
JavaScript standard, as now Function.prototype.bind gets overridden
with an incompatible version. And it also is too late for MooTools
to change that now, as such a change would break all depending code
at once.
It's an either-or situation. Users of MooTools
, for reasons explained in my
previous email.
But this means libraries like MooTools automatically break the JavaScript
standard, as now Function.prototype.bind gets overridden with an incompatible
version. And it also is too late for MooTools to change that now, as such a
change would break
On Fri, Apr 30, 2010 at 5:50 PM, Brendan Eich bren...@mozilla.com wrote:
On Apr 30, 2010, at 5:33 PM, Jürg Lehni wrote:
[...]
Yes, jQuery nicely avoids the whole prototype issue.
What do the spec contributors have to say about scripts that modify built-ins?
The concept don't modify objects
.
I think it's better to leave ES5 Function.prototype.bind as specified,
based on Prototype's bind (and others like it), which take positional
arguments to partially apply.
Yes, that's what Allen Wirfs-Brock told me, though it wasn't forwarded
to the list. I included my reply to his message
);
Function.prototype.bind.apply(targetFn, boundArgs);
Which is not very elegant of course (first version also takes a
performance hit by creating unnecessary Array object).
But it gets the job done.
I think it's better to leave ES5 Function.prototype.bind as specified,
based on Prototype's bind (and others
On Nov 4, 2008, at 10:43 AM, David-Sarah Hopwood wrote:
The bug that Brendan and I were referring to was 61911:
https://bugzilla.mozilla.org/show_bug.cgi?id=61911
For reference so new readers don't have to look far back in the old
thread.
On FF3.0.3, a bit of testing reveals that
On Aug 13, 2009, at 1:07 PM, Brendan Eich wrote:
On Nov 4, 2008, at 10:43 AM, David-Sarah Hopwood wrote:
[...]
callable
regexps were a SpiderMonkey extension never adopted by any non-
Mozilla
JavaScript implementation AFAIK, and they introduce an irregularity
in
the language.
Not so.
On Aug 13, 2009, at 1:28 PM, Juriy Zaytsev wrote:
There was a discussion of this ticket on Hacker News this morning
and we had this slight confusion on whether giving RegExp objects a
[[Call]] property is permitted by spec http://news.ycombinator.com/item?id=760529
. I thought it was, since
On Aug 13, 2009, at 4:44 PM, Brendan Eich wrote:
On Aug 13, 2009, at 1:28 PM, Juriy Zaytsev wrote:
There was a discussion of this ticket on Hacker News this morning
and we had this slight confusion on whether giving RegExp objects a
[[Call]] property is permitted by spec
Subject: Re: Callable RegExp vs. typeof (was: Re: Draft of
Function.prototype.bind.)
On Aug 13, 2009, at 1:28 PM, Juriy Zaytsev wrote:
There was a discussion of this ticket on Hacker News this morning
and we had this slight confusion on whether giving RegExp objects a
[[Call]] property
Allen Wirfs-Brock wrote:
The Kona minutes state bind behavior: Should bind create only a call or
both a call and a construct bound property? We decided to stick to last
meeting's decision of creating both a call and a construct bound property.
[...]
I was originally going to talk about various
David-Sarah Hopwood wrote:
Allen Wirfs-Brock wrote:
[...]
6) bound functions have a prototype property that is initialized to the
value
of the target function's prototype property. Both construction and
instanceOf use the bound function's prototype value.
6a) bound functions have a
The Kona minutes state bind behavior: Should bind create only a call or both a
call and a construct bound property? We decided to stick to last meeting's
decision of creating both a call and a construct bound property. (If it were
just call, then the argument for adding bind to the language at
Mark S. Miller wrote:
11. If the [[Class]] property of /G/ is *Function*, then
1. Get the *length* property of /G/.
2. Let /L/ be Result(11a) minus the length of /A/.
What does minus mean here? Result(11a) could be anything.
Waldemar
On Mon, Nov 10, 2008 at 4:48 PM, Waldemar Horwat [EMAIL PROTECTED]wrote:
Mark S. Miller wrote:
11. If the [[Class]] property of /G/ is *Function*, then
1. Get the *length* property of /G/.
2. Let /L/ be Result(11a) minus the length of /A/.
What does
On Nov 6, 2008, at 9:58 PM, Allen Wirfs-Brock wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:es3.x-discuss-
[EMAIL PROTECTED] On Behalf Of Brendan Eich
Sent: Thursday, November 06, 2008 8:05 PM
...
TC39 has generally avoided adding new globals; JSON is it for ES3.1
of Function.prototype.bind.
On Nov 6, 2008, at 9:58 PM, Allen Wirfs-Brock wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:es3.x-discuss-
[EMAIL PROTECTED] On Behalf Of Brendan Eich
Sent: Thursday, November 06, 2008 8:05 PM
...
TC39 has generally avoided adding new globals; JSON
: [EMAIL PROTECTED] [mailto:es3.x-discuss-
[EMAIL PROTECTED] On Behalf Of David-Sarah Hopwood
Sent: Thursday, November 06, 2008 5:11 PM
To: es-discuss@mozilla.org; [EMAIL PROTECTED]
Subject: Re: Draft of Function.prototype.bind.
Brendan Eich wrote:
On Nov 4, 2008, at 10:52 AM, David-Sarah Hopwood
On Nov 6, 2008, at 5:11 PM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
On Nov 4, 2008, at 10:52 AM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
We'll make regexps non-callable in a future release whose numbering
allows us to break compatibility for all the users who may be
relying
-Original Message-
From: [EMAIL PROTECTED] [mailto:es3.x-discuss-
[EMAIL PROTECTED] On Behalf Of Brendan Eich
Sent: Thursday, November 06, 2008 8:05 PM
...
TC39 has generally avoided adding new globals; JSON is it for ES3.1
(AFAIK), and since Murphy was an optimist, it is breaking
On Nov 4, 2008, at 12:11 PM, David-Sarah Hopwood wrote:
The correct fix is to make RegExp objects noncallable. This matches IE
and Opera's behaviour and so will not break the web.
Careful. We can reason about breaking the web if something disagrees
with IE, but not all JS implementations
On Mon, Nov 3, 2008 at 10:55 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
I'm sure people may have an opinion one way or the other, I just don't know
of any Web content actually broken by this in practice. I don't have strong
feelings on the matter in either direction, just reporting our
Mark S. Miller wrote:
For Cajita, the only issue is RegExps. Host objects are such a disaster of
unspecified vagueness and random browser behavior that we never expose hosts
objects directly to cajoled code. Rather, we intermediate all access to host
objects through our taming layer. Other
On Nov 4, 2008, at 19:11 , Mark S. Miller wrote:
I suggest that, for non-host objects, we change the ES3.1 spec so
that |typeof F === 'function'| iff the [[Class]] property of F is
Function. For host objects, the spec would continue to allow them
to return whatever the func they want ;).
On Nov 4, 2008, at 10:43 AM, David-Sarah Hopwood wrote:
Can someone provide a link to this bug, or to that prior discussion
of this
bug? Thanks.
Sorry, I meant to post that before.
The bug that Brendan and I were referring to was 61911:
https://bugzilla.mozilla.org/show_bug.cgi?id=61911
On Nov 4, 2008, at 10:52 AM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
We'll make regexps non-callable in a future release whose numbering
allows us to break compatibility for all the users who may be
relying on
this JS extension.
What's wrong with that release being the one that
1 - 100 of 128 matches
Mail list logo
