At the risk of pointing out the obvious:
```js
const privkey = Symbol();
const stores = new WeakMap();
class A {
[privkey] = {};
constructor() {
const priv = {};
priv.hidden = Math.random();
stores.set(this[privkey], priv);
}
get hidden() {
const priv = stores.get(this[pr
What exactly are you proposing to do differently than String.raw?
https://developer.mozilla.org/en-US/docs/web/javascript/reference/global_objects/string/raw
Sent from my phone
From: es-discuss on behalf of Andrea
Giammarchi
Sent: Monday, June 22, 2020 12:24:13
For the record, I proposed this feature before, and it wasn't seen as a good
idea, for some reason:
https://esdiscuss.org/topic/function-is-not-mandatory#content-47
Given how close ES6 is to ship, I think it's too late to make such changes to
the spec, we will have to live with it. Use Traceur t
± > var o = {};
± > var p = new Proxy(o, { get: function(o, p) { return o[p]; } });
± > o.__proto__ = p;
±
± This does nothing on its own in Firefox, afaict.
± If I then do "o.foo" I get a "too much recursion" exception, as expected.
±
± What is the problem, exactly?
I typed the line
Hi,
I just had an horrible idea which can DDOS Firefox or hangs your tab in IE:
var o = {};
var p = new Proxy(o, { get: function(o, p) { return o[p]; } });
o.__proto__ = p;
This works because of the cycle detection for setting prototypes. Should it?
Best regards,
François
__
Please note that you do not really create a one-shot function and garbage in
this case, at least if the compiler does his job well. The F# compiler, and
probably many functional language compilers, would correctly inline the lambda
function here.
There’s probably no reason a JavaScript comp
I believe in the future experimental features will stay in modules that can be
imported (“import WeakMap from “@weakref-moz-experimental””), making the
prefixing problem less critical. In such case, if you want your code to be
bullet-proof, you simply do not rely on features marked as experiment
± How would you suggest to deliver an application over internet (e.g.
± myapp.zip)? Isn't that a bundle already?
This claim is bogus. In all the cases I know, the packages are unzipped by the
OS before running the application, and the application itself has no need to
know anything about the pac
/webappstore/wiki/Manifest
There are a lot of links you can follow from there.
De : Andrea Giammarchi
Envoyé : samedi 26 octobre 2013 23:29
À : François REMY
Cc : 'Ilya Grigorik', es-discuss
Apologies, I just answered what Ilya answered but I'd like to see this
discu
I can’t help but repeat, what you describe is called an app package format.
Windows 8 has one, Chrome has one, Firefox OS has one; others may have one,
too. There are discussions about a standardized app package format going on,
but they are not happening on es-discuss.
Why do you think this
± > Because using a ZIP file is a bad practice we certainly should not
± > allow. As stated before, it will make the website slow [...]
±
± It seems what you're saying is that there are already superior ways to bundle
± JS modules and we don't need W3C to define another one.
± Perhaps—but this def
± > HTTP 2.0 can send you multiple files in parallel on the same connection:
that
± way you don't pay (1) the TCP's Slow Start cost, (2) the HTTPS handshake and
± (3) the cookie/useragent/... headers cost.
±
± Doesn't connection:keep-alive deal with (1) and (2) nicely?
You still have to pay it 6
± You're not saying that gzipping and wise pre-fetching and parallel download
± of scripts don't improve page load times. Or are you?
All servers serve GZIPPED version of text files. You don't need a ZIP for that.
HTTP 2.0 can send you multiple files in parallel on the same connection: that
way
> Tiny bike-shed-ish comment that we need a linking punctuator so that
> arrow function syntax can be extended likewise:
>
> var f = function (x, y) : (z) {...}
>
> Arrow form showing expression body:
>
> var f = (x, y) : (z) => x*y/z;
FWIW, I like the semi colon. However, I prefer
| function
> We've found the need for serializable functions in AmbientTalk, which,
> like JS, encourages a style of programming that makes significant use
> of lexical nesting. We have found that this programming style makes
> that requiring serializable functions to be closed is indeed too
> restric
>> TLDR ==> The web needs a way to express executable code that does not rely
>> on its parent context, is guaranteed to be side-effect-free, and can be
>> executed safely anywhere (even in a different thread/worker/window/device,
>> or as callback for browser code being executed while the DOM i
> Le 26/09/2013 15:36, Bradley Meck a écrit :
>> The only really think of that would be of benefit is parallel execution.
> MongoDB MapReduce exploits parallelism as much as one can ever hope and
> just a string generated from
> var f = '' + function(){...}
> seems to work just fine.
Firstly, this
Hi,
It's been some time I've been working on this idea of a Closure-free,
Serializable function. This kind of function would have no access to the parent
closures they are defined in, and only limited (read-only) access to the
enclosing environment (read-only Math, Object, Array, others...).
T
> Hi François, your goals here have a
> tremendous overlap with SES. In what
> ways is SES not satisfactory for
> these purposes?
Sorry for the late reply, I did take some time investigating SES and the
implications. Basically, it seems SES provide the required guards in this case
(untouched +
happy but this is not my objective. As I said, I would settle on
making it impossible to return any environment-based function (make them
unserializable) if it can make this proposal more robust.
> On Wed, Sep 25, 2013 at 4:29 PM, François REMY
> mailto:francois.remy@outlook.
Hi,
TLDR ==> The web needs a way to express executable code that does not rely on
its parent context, is guaranteed to be side-effect-free, and can be executed
safely anywhere (even in a different thread/worker/window/device, or as
callback for browser code being executed while the DOM is not r
> At the last TC39 face-to-face, the committee agreed to normalize CR, LF
> and CRLF to LF in template strings[0]. Since then, it's become clear
> that LINE_SEPARATOR and PARA_SEPARATOR were overlooked. The question to
> resolve is: should these also be normalized?
What's the use case for n
> It sounds like you are saying that generators are too high-level, and
> it would be better to expose a lower-level primitive.
>
> But what would that lower-level primitive be? What operations would it expose?
State machines. As you can see for your Traceur example, there are two things
here: th
Hi, I'm back. Not sure I totally figured it out, but I thought it was probably
time to "yield" my reasoning before iterating further ;-)
To achieve a different result, I figured out we probably needed to start from a
different sets of initial assumptions. So here are my new set of assumptions:
> > I've come to learn the TC39 committee members
> > usually have good ideas even if they seem bad initially.
> > I hope this is the case again this time...
>
> That is nice to hear, and quite a track record to live up to.
> On behalf of all TC39 if I may, thanks.
Well, I don't think I deserve
> [...] The only contextual knowledge the reader
> needs in order to know this is that there are no
> intermediate function definitions within f
> wrapping code sequence 2 -- i.e., that code
> sequence 2 is code of the function f itself, as
> opposed to code of a function within function a.
> It s
I know pretty well I’m probably not going to convince the believers here, but
this whole “we need an indication at the beginning of the function” thing is
kinda not making sense.
For starter, the generator function always starts at its first line. If what
you {Till Schneidereit} mean is that t
> Wait, what? The semantics of the web demands that runaway JS block any other
> even turns, or page layout/rendering from proceeding. Multi-process browsers
> can prevent cross-origin pages from interfering with each other, and Servo
> can do speculative layout to reward well-behaved pages, but
> Because the location info will be that of the "new Error"? One could
> try this instead, which seems to work for me:
>
> throw { __proto__ : new Error(), reason: "Monday" }
That one seems to be working (except in IE<11 since IE didn't support __proto__
prior to that). That somehow surprises me
> ```javascript
> function CustomError(message) {
>this.message = message || '';
> }
> CustomError.prototype = new Error;
>
> // whenever you need
> throw new CustomError;
> ```
At best, this will not preserve the stack trace property, at worse this will
lead to a bad one.
In some browsers, using the native Error class enables cool features like
automatic stack trace.
Just in case you need special kind of Error (ie: subclasses), I recommend doing
it that way:
function SomeError(message) {
// the real instance should be an Error:
var self = new Error(m
There is an issue when the argument of an
intended parenthesis-free function call
happens to begin with a parenthesis.
Just like there are issues if you want to return an object literal from a
lambda in JS, you've to use parentheses around it. Not a big deal.
Anyway, I'm not saying we should
I'm maybe biased, but I would love to consider "yield" as a function.
Indeed, it calls another code, which can return you a value. That looks very
similar to a function call to me. If we do this, the predecence becomes
intuitive again:
var x = yield(a) + yield(b);
yield(a+b);
I think th
The sentence
If a key is duplicated, a parser SHOULD reject.
is not a change. It is implied by the first statement.
I do not agree. A 'should' authoring requirement is not meant to trigger an
abortion from the execution engine.
For example, the CSS flexbox spec says that an author shou
Arrow functions probably shouldn’t be used for this, this is not very readable.
I think you should have a look at modules, this is what is expected to replace
this pattern ;-)
> From: jo...@jorgechamorro.com
> Subject: IIAFEs?
> Date: Sat, 1 Jun 2013 23:
> If against all odds, all code everywhere *did* magically drop __proto__
> in favor of Object.setPrototypeOf, then SES and similar subsets would be
> unable to protect secure code from ambient Object.setPrototypeOf usage
> from the insecure side on the secure side's objects, unless
> Object.setPro
I certainly agree, but it has been decided otherwhise by the TC39 members and I
doubt they’re willing to revert their decision.
De : Andrea Giammarchi
Envoyé : 18 mars 2013 17:08
À : Nathan Wall
Cc : es-discuss@mozilla.org
Objet : Re: Mutable Proto
I would like to see Object.set
> The script engine does not relate to clicking on things -- that
> happens in a browser. So do you feel that script engines must ship
> with a console? Or does that apply to web browsers? And if so, why?
As Brian said, the UI itself should not be defined in the spec. However, I feel
like the obj
> In browsers, when logging an object, you can actually click on an arrow
> to browse through all its properties.
> Serializing the whole thing on every single console.log, when those
> happen in a loop,
> would make the debugging experience a nightmare, performance-wise.
True but we may expect th
> I don't know if native objects have a mutable [[Prototype]] (by
> assigning __proto__) but if they do, then one solution might be to have
> your native objects inherit from a proxy. The proxy should then be able
> to intercept all missing properties, as I once
> sketched:
> https://mail.mozi
> Do you have links to spec saying that the browser adds native event
> handlers?
Here you are:
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html#events-in-decorators
> The best that can be done here is contact the DOM Core people (that's
> where events are now apparently),
> In this instance, it's possible for you as a polyfill author to replace
> Element.prototype.style by your own getter which returns your special
> proxy objects which do what you expect on property set.
For the style case, it's *maybe* possible to do so (in a WebIDL compatible
browser at least,
> >> I think such a getter notation exists in WebIDL to formalize scars from
> >> the past (like HTMLCollection) rather than to be used in new APIs
> > Yes and no. For exemple, something alike is envisionned to support custom
> > properties in CSS. Something like:
> >
> > element.style.myCustomPro
> > Let's say I want to implement a polyfill for MapEvent whose definition is
> > as follows:
> >
> > interface MapEvent : Event {
> > getter any item(DOMString name);
> > }
> Out of curiosity, where does MapEvent come from? I can't remember having
> read about it on any spec and Google isn't help
Hi.
I must admit I didn't follow the whole thread about native element
proxyfication but when I left the consensus was that the native element should
not be proxied (ie: it would not work like Object.create(...) do not work for
them).
I've however a compelling use case that may make some of us
Good idea. However, I don't like the fact "arr.forEach(f,null,-1,0)" doesn't
walk the array backwards properly. Not sure it's worth to have it built-in
though.
> Date: Thu, 24 Jan 2013 12:06:23 +0100
> Subject: Array method ranges
> From: e...@qfox.nl
> T
> We could, however if iteration order is eventually defined it would be
> kind of annoying if we sorted things.
Even if iteration order is going to be defined in some way, I doubt it will be
intuitive in any way. But I could be wrong, this is just a personal belief.
Just to return back on the initial question:
> The event stuff is a distraction and was merely to illustrate. See
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20158#c1 For the APIs
> we define in "DOM-land" we aim to have them fully deterministic even
> when developers do strange things.
Why
> >> When later getting that node out of the DOM with .firstChild, what
> >> should be handed back? The proxy that was passed in, the JS object
> >> that proxy was wrapping, something else (e.g. an exception is thrown)?
> > The principle of least surprise would say the proxy that was passed in
>
>
> We could potentially switch from magic to private symbols but DOM
> bindings are highly optimized and I don't think we could afford making
> these use symbols. (Right now the pointer is stored at a statically
> know offset of the js object.)
Can we use both systems in parallel? In case you hit t
ed".
>
> I assume we have no solutions now and no solution is discussed, am I correct?
>
> thanks
>
>
> On Tue, Jan 8, 2013 at 12:53 PM, François REMY
> mailto:francois.remy@outlook.com>>
> wrote:
> This is a known problem called Object identity
This is a known problem called Object identity. We already have this problem
today with Object.create(document.createElement("p")) which is an "instanceof
HTMLElement" but is invalid for any DOM purpose.
However, if you take the same P element and set its __proto__ to null, it will
still be a
> Nothing's unfair about designing by use-cases, and that's how a lot of
> the Web standards roll.
I'm not sure I'm on topic because I didn't go throug the full thread, only a
few mail, but what about the case of non-constructible DOM objects?
Until recently (still now on IE) you could only cre
> Date: Mon, 7 Jan 2013 18:00:59 +0100
> From: ann...@annevk.nl
> To: francois.remy@outlook.com
> CC: www-...@w3.org; es-discuss@mozilla.org
> Subject: Re: Better event listeners
>
> On Mon, Jan 7, 2013 at 5:42 PM, François REMY
Hi Anne,
Thanks for bringing the case of event registration, this has been a pain in
DOM/JavaScript for some time already and it's quite clear we can do better
in this area.
However, I've a few issues with your latest proposal:
- how do you register more than one handlers for an event?
> Ah - true. They can put a "use strict" at the top if they want that.
It’s also possible that Node.js will just enable strict mode by default (as
soon as it’s faster than the non-strict mode, which should happen soon); when
they will do so, it will mean that using the non-strict mode wil
|
| The idea is to not do the processing if the JSON parsing fails.
|
Then, why not just nest your try's? For readability reasons?
var info, processed;
try {
info = JSON.parse(json);
try {
processed = process(info);
} catch(ex) {
...
}
| That just puts 'body' on the window.
Indee, I'm false on that one. But if you use a direct eval, you can get the
same behavior in ES5, which is want I wanted to demonstrate:
window.a = true;
(function x(t) { eval(t); return a==window.a; })("var a=false")
So in plain ES5, the scope of
Indirect eval is something introduced for ES5 Strict only, I believe. Try
the following code in your browser’s console, and you may be surprised:
((function(t) { t("var body=true"); return function() { return
body; }; })(eval))())
___
es-discuss ma
one might consider a with parse-on-use semantics
Sounds like yet another "use strict" to me. Experience tells that this is
not working very well. Either an optimization is worth and is enforced by
default, or it isn't us
I think that what he meant is that we know for sure in which scope we can find
the property/variable. That the propery exists or not in the that scope is
another issue.
So, in the code “function getOoops(t) { t(); return function() { return ooops;
} }” we know statically that the scope where th
code that emulate the syntaxFeature
/* @endif */
*/
There's probably an anwser to that question, it's just that I'm not aware of
it already :-)
-Message d'origine-
From: Brendan Eich
Sent: Tuesday, September 18, 2012 7:17 PM
To: François REMY
Cc: Luke H
| But if we have macros, then many progressive
| enhancement and anti-regressive polyfill approaches can be done, even
| with new syntax (not just with APIs).
Seems like another good way of fixing the issue :-) However, this seems to
require some form of conditionnal compilation to work , rig
(Just one opinion)
I'm all in favor of function-level parse errors. This reminds me an article
of Ian Hickson where he wondered why, to the contrary of CSS, the ECMAScript
language didn't define a generic syntax defining a well-formed program
(tokens, parenthesis+brackets balance, ...) and whi
From: Rick Waldron
Nit: "Object.makeBindable" sounds like: "prepare this for bindability",
but "bind" is already a concept in the language, where
Function.prototype.bind creates a new function object from an existing
function object, but with a BoundThis as specified by the thisArg in
fn.bind
From: Alex Russell
Sent: Thursday, August 30, 2012 7:44 PM
To: ste...@stevensanderson.com
Cc: es-discuss@mozilla.org
Subject: Re: Object.observe and observing "computed properties"
On Wed, Aug 29, 2012 at 11:09 AM, Steve Sanderson wrote:
Knockout developers are used to this sort of thing
ch listened specifically
to array events and managed the DOM as a close copy of the array using a
binding template; those 'insert' and 'delete' events could be transferred to
a 'made-observable' arrays.
-Message d'origine-
From: Rafael Weinstein
Here’s my take on the binding thing:
http://fremycompany.com/BG/2012/ECMAScript-Binding-Manager-951/
Key features:
- Do not require to have a reference on an object to bind to it (binding is
implicit and managed by the browser).
- Accessors, function calls and inner dependencies are managed autom
Symbol could already be used by parsers and compilers. What about UniqueName?
-Message d'origine-
De : Rick Waldron
Envoyé : 01/08/2012 22:34
À : Mark S. Miller
Cc : es-discuss
Objet : Re: The Name of the Name
On Wednesday, August 1, 2012 at 4:26 PM, Mark S. Miller wrote:
I lik
o.{
a.b = 6;
c.f();
a.b = a.c; // !!
};
This is indeed an issue that could be solved using
o.{
.a.b = 6;
.c.f();
.a.b = .a.c;
}
My previous sample would be rewritten :
var style = "color: red";
var elem = document.createElement("span");
elem.{
From: T.J. Crowder
I'm worried this looks a lot like `with` -- with the same issues. Is the
idea that unqualified references would be _required_ to be properties of
the object in question?
This looks like a with regarding some points, but this is cleary not a with.
I think
var style =
If I correctly understood, A is for the supposedly existing case where someone
would add a property to an object before you “extend.{}” it to alter the way
that property is handled, in order to get acces to things you wouldn’t have
thought they could gain access to but that you’re putting on a p
While we're at it, I had an idea to allow to avoid the function*() {}
syntax: why not "yield [noLineTerminator] return" ?
Since "return" is a reserved word which can only appear as first token of an
instruction, enforcing [noLineTerminator] makes sure any recognized use of
'yield return' in ES
Avocating against the use of “new” is both a bad idea (not clear enough) and a
source of problem :
For exemple, in Chrome (latest version), you get some weird things:
XMLHttpRequest()
TypeError: DOM object constructor cannot be called as a function.
Best regards,
François
From: Axel Rauschmayer
I kinda like it. My preferred being:
arr.map(return '<'+$0+' class="'+this.getClassName($1)+'"/>')
BTW, to respond to @TabAtkins, I know by experience that a very large amount
of lambdas have 'a', 'b', 'c', 'x', 'y' and 'z' as argument names, because
lambdas are short and have an obvious us
Sent: Saturday, March 17, 2012 9:33 PM
To: François REMY
Cc: Brendan Eich ; Allen Wirfs-Brock ; es-discuss
Subject: Re: Let's replace <| with :: (was Breaking up the <|...)
François REMY wrote:
Wouldn't it be better to use 'as' for guards? Seems more intu
Wouldn't it be better to use 'as' for guards? Seems more intuitive and
easier to type
let A as Number = 3;
let B as Email = "x...@google.com";
class ListNode {
public nextNode as ListNode;
public value; // no guard
}
However, it is'nt a reserved keyword. But I don't t
Stunned to read that from someone asking for the arrow syntax, but yes, it’s
right.
From: Axel Rauschmayer
Sent: Sunday, March 11, 2012 2:46 PM
To: François REMY
Cc: es-discuss
Subject: Re: Callable values: trying to summarize
BTW, if we are still going to make 'fn' optionnal,
I think it's a good summary of current state of the art. Personally, I'm
all-in with "do(args){}" syntax because it's the syntax that best fit (my)
intuition a well as the current ES syntax (both of a function and of a
block). The arrow syntax is ackward and requires you to read upto the arrow
eter van der Zee
Sent: Friday, February 10, 2012 12:01 PM
To: François REMY
Cc: es-discuss
Subject: Re: Fallback
On Fri, Feb 10, 2012 at 11:51 AM, François REMY
wrote:
The idea would be that each time the parser hit an issue, it replaces the
current block by a { throw new InvalidProgramException(); }
Microsoft tried your solution, it's called condtionnal compilation. Now,
they are removing that from HTML because it's a bad pattern.
A better solution would be to change the way a code break when he encounter
a syntax error.
let supportsBlockLambda = true;
try { let l = {|| true}; } ca
Just to confirm: you are not alone. I always thought that allowing to imply
local this (‘this.’) was a bad idea (C#). Seriously, this is not 5 chars
that’ll hurt but it could make IDE work a lot easier, and it make code reuse
more efficient (if you need to copy/paste some code, if you stay in th
-Message d'origine-
From: Brendan Eich
> François REMY <mailto:fremycompany_...@yahoo.fr>
> January 21, 2012 1:34 AM
> About the 'fn' proposal, I'm happy with it. Asking a 'use' statement
> just for that feature may prove a little excess
(sorry, last mail was sent by mistake)
This seems pretty easy to enforce to me.
function a(x) {
let count = 0;
let arr = [
(x+1)^(x-1),
(x*x),
(2*x-1)
];
arr.forEach({|x|
if((x&1)==0) count++;
});
return count;
}
can be compiled as :
function a(
(sorry, last mail was sent by mistake)
This seems pretty easy to enforce to me.
function a(x) {
let count = 0;
let arr = [
(x+1)^(x-1),
(x*x),
(2*x-1)
]
arr.forEach({|x|
if((x&1)==0) count++;
});
return count;
}
can be compiled as :
function a(x
anuary 21, 2012 2:08 AM
To: François REMY
Cc: es-discuss
Subject: Re: Block lambda is cool, its syntax isn't
Rust is a static language with many guarantees. It's not really
comparable to JS here.
JS extended with block-lambdas has no way to force downward-funarg-only
contract on function
About 'ƒ': on my keyboard, there's no way to type it. I have to use ALT+its
UTF8 keycode, and it doesn't work in all programs. BTW, since the default
file format on Windows is not UTF8, expect many developers to use ISO-8859-1
for their JS files. Personnaly, I use Notepad++ which allow me to use
Just to add weight to my previous mail, you may find it interesting to
notice that my proposed syntax match nearly exactly the proposed syntax of
the new Mozilla-editored Rust programming language:
http://doc.rust-lang.org/doc/tutorial.html#closure-compatibility
call_twice({|| "I am a stack
cript minizers without checking
if ‘this’ is used in the function or not, I guess I can live without that (to
the condition that I can do that: @(this=this, x) this.transform(x)).
I hope I’ve been more clear than in my previous mail,
François
-Message d'origine-
From: Brenda
ction() { ... { ... return; }
... }” are not covered properly by block lambda, nor are intended to.
From: Axel Rauschmayer
Sent: Thursday, January 19, 2012 10:14 PM
To: Brendan Eich
Cc: Andreas Rossberg ; François REMY ; Oliver Hunt ; es-discuss Steen
Subject: Re: Block lambda is cool, its syntax isn&
#x27;s no since it has no visible effet. If they don't
reference variables of a scope, they should not use reference scope and may
be reused accross function calls.
-Message d'origine-
From: Brendan Eich
Sent: Thursday, January 19, 2012 8:27 PM
To: Axel Rauschmayer ; Andr
To be fair, after a long reflection, I have been concluding that no other
proposal beat {|| ...} for block lambda at this time. Also, I’ve found some use
cases where block-lambda are actually useful (something I was really curious
about before thinking about it). In the future, they may even be
If I just can add my own two cents about the naming convention :
get(key)
get(key, valueIfMissing)
set(key, newValue)
getOrSet(key, newValueIfMissing)
// kinda like openOrCreate on most file systems
François
-Message d'origine-
From: Herby Vojčík
Sent: Tuesday, Janua
Does it really make sense? If your goal is to return a value, using
'continue' is a lie. You may for exemple write "continue false" to break a
loop or return from an event. It has nothing to do with a continue
statement. A continue statement should be the complementary part of a break
statement
I’ve a question about block lambda. What will be the output of the console for
this code :
let numbers=[1,2,3,4,5,6];
let isPair=function(x) {
console.log(x); return (x&1)==0;
}
function getAnyWhere(elements, isValid) {
elements.forEach({(x) if(isValid(x))
I tend to prefer the parentheses because pipes are not "logical" for arguments
and, worse, they are very difficult to type on many keyboard layouts. On mine
it's AltGr+1. I tend to use it very fewly.
But I'm not saying my personal taste is universal.__
Am I wrong if I say there not a bigger issue with block lambda than with the
current object notation on the matter?
I mean, does that code mean anything useful?
function() {
{|a,b| a+b};
}
If not (as it seems to me), it means that a block lambda will not be used as
a statement by
, 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 wrote:
Such an implementation would
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
nctions]]
- 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
O
1 - 100 of 141 matches
Mail list logo
