There was a suggestion for CoffeeScript, which got implemented by
Cocohttp://satyr.github.com/cup/#c:%7B+enumerable,%20-configurable,%20+writable%7D,
for `{+enumerable, -configurable, +writable}` syntax that does that. It has
the same potential ambiguity, but looks better IMO.
On Thu, Jan 5, 2012
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
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
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 4 January 2012 21:27, Brendan Eich bren...@mozilla.com 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 --
On 4 January 2012 21:30, Brendan Eich bren...@mozilla.com 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...
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
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
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
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
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
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
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
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 is that
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
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
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
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
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
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
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
On Thu, Jan 5, 2012 at 10:13 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
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
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
On Jan 5, 2012, at 10:20 PM, Mark S. Miller wrote:
On Thu, Jan 5, 2012 at 10:13 PM, Allen Wirfs-Brock al...@wirfs-brock.com
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
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
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
34 matches
Mail list logo
