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 =
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
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
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
± 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 one
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
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
± 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
± 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
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
/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
discussion ... where
± 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
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
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
|
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
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: the
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 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
[...] 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
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 such
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
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
```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.
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 IE11 since IE didn't support __proto__
prior to that). That somehow surprises me that
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
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
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
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
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
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
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 the
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
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:
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
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 helping.
Just to
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.myCustomProperty = true;
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,
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), and
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
To:
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 not
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.
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
That's
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
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
8, 2013 at 12:53 PM, François REMY
francois.remy@outlook.commailto:francois.remy@outlook.com
wrote:
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
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 the
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?
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
francois.remy@outlook.com
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 will
|
| 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) {
...
}
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
one might consider a script provide 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 used in most cases. Asking the developer to mark his
code
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
| 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
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 Hoban ; Andreas Rossberg ; Paul
(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
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 fla...@gmail.com wrote:
Knockout developers are used to this
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(
REMY ; Steven Sanderson
Subject: Object.observe and observing computed properties
Steve Sanderson (author of the excellent KnockoutJS framework) and
François REMY both raised the issue of observing computed properties
WRT to the Object.observe() proposal.
Having thought about this problem while
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
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
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
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 ES6
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
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 use.
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 intuitive and
easier to type
let A as Number = 3;
let B as Email = x...@google.com
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
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
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}; }
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
fremycompany_...@yahoo.fr wrote:
The idea would be that each time the parser hit an issue, it replaces the
current block by a { throw new InvalidProgramException
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
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
, 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 functions called with block
(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((x1)==0) count++;
});
return count;
}
can be compiled as :
function
(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((x1)==0) count++;
});
return count;
}
can be compiled as :
function
-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 excessive but if it can be
merged with other can-be-breaking
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: Brendan Eich
Sent: Friday, January 20, 2012 12:28 AM
To: François REMY
Cc: Axel Rauschmayer ; Andreas Rossberg ; Oliver
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
-
From: Brendan Eich
Sent: Thursday, January 19, 2012 8:27 PM
To: Axel Rauschmayer ; Andreas Rossberg
Cc: François REMY ; Oliver Hunt ; es-discuss Steen
Subject: Re: Block lambda is cool, its syntax isn't
Axel Rauschmayer mailto:a...@rauschma.de
January 19, 2012 9:31 AM
Rationale: wouldn’t
() { ... { ... 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't
FTR
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
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.
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
]]
- 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
, 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
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
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
Doesn't play nice with already existing blocks :
eval({ !window }) // returns false;
Regards,
François
-Message d'origine-
From: Herby Vojčík
Sent: Wednesday, January 04, 2012 12:49 PM
To: es-discuss@mozilla.org
Subject: Boolean shortcuts
(original article in
I agree that code block is a complex feature that is (almost) never used and
that has many quirks.
If ES6 could remove it, I would not be upset at all. If it's here to stay,
we should at least have an introductory keyword like eval { ... } and
allow var x = eval { ... }.
BTW, I think the
If someone use ES6 features while the spec isn't done yet, he takes the risk
of having his code breaking as the specification evolve.
In this case, he would have to rewrite his code as
var foo = function() {
eval {
let x = 42;
console.log( x );
}
should drop labels for ES6. This will help to simplify
syntax, too. With ES6, we should build a new syntax that’s more logical to use.
-Message d'origine-
From: Mike Samuel
Sent: Wednesday, January 04, 2012 9:17 PM
To: Herby Vojčík
Cc: François REMY ; es-discuss@mozilla.org
Subject
Is breaking current code so much of a problem? If, by default, javascript
refers to ES5 and if we introduce a use version 6 pragma, breaking old
code isn't a problem anymore. Scripting languages on UNIX are doing exactly
this [http://en.wikipedia.org/wiki/Shebang_(Unix)]. The first line
aside note
let x = q ? 10 : 20;
Why we're reinventing the wheel here is up to me.
/aside
-Message d'origine-
From: Dmitry Soshnikov
Sent: Friday, November 11, 2011 8:54 AM
To: David Herman
Cc: es-discuss Steen
Subject: Re: (Almost) everything is expression
On 11.11.2011
: Friday, November 11, 2011 10:42 AM
To: François REMY
Cc: David Herman ; es-discuss Steen
Subject: Re: (Almost) everything is expression
On 11.11.2011 13:26, François REMY wrote:
aside note
let x = q ? 10 : 20;
Why we're reinventing the wheel here is up to me.
/aside
I noted
be
the return value of the latest statement evaluated in the block. The problem
is that it may be unknown at compilation time... or isn't it?
-Message d'origine-
From: Dmitry Soshnikov
Sent: Friday, November 11, 2011 12:21 PM
To: François REMY
Cc: David Herman ; es-discuss Steen
Subject: Re
In my understanding, super would be null.
What would be more complex is :
var widget = {
hookup: function() {
// |this| is widget
// |super| is widget
window.addEventListener('load', function(event) {
// |this| is widget
// |super|
11, but then you’ve no
way to solve the asynchronous pattern (super would remain null and only this
would be bound).
François
From: John J Barton
Sent: Saturday, October 01, 2011 6:16 PM
To: François REMY
Cc: Brendan Eich ; Axel Rauschmayer ; es-discuss
Subject: Re: Super-calls
On Sat, Oct
1 - 100 of 128 matches
Mail list logo
