I'm just stumbling over a little improvement (syntactic sugar) that
could help to make code a bit smaller (- less to debug, read,
understand, etc. pp.)
When you want to pass additional parameters to the Array.forEach()
callback function you currently must work with an additional (anonymous)
I think extending standard libraries/functions is not the most elegant
approach. I think what you suggest is basically trying to bind some parameter
that isn't the first few continuous parameter (in this case, it is the 4th
parameter) while keeping the first few parameter unbound. I believe
I have just sent this proposal through
http://www.ecma-international.org/memento/register_TC39_Royalty_Free_Task_Group.php
but I don't know what more I need to do. I am a high school student from China
who is interested in next-generation ecmascript and has been working on an
ecmascript
On Wed Dec 17 10:30:03 PST 2014, Andrea Giammarchi wrote:
This would already fix the `Object.prototype.get` or `.set` case since I
believe nobody ever used an inherited `value` property on purpose for
descriptors ... or is it?
I agree that nobody will use an inherited 'value' property, however,
On Fri, Dec 19, 2014 at 8:55 PM, caridy car...@gmail.com wrote:
inline...
On Dec 19, 2014, at 3:21 PM, James Burke jrbu...@gmail.com wrote:
...
* How does dynamic loading work in a web worker? In general, how does
dynamic loading work when there is no DOM.
think about this as nodejs
It will not block, modules are async by nature. what make you think this
proposal implies blocking?
Sent from my iPhone
On Dec 20, 2014, at 1:04 PM, John Barton johnjbar...@google.com wrote:
On Fri, Dec 19, 2014 at 8:55 PM, caridy car...@gmail.com wrote:
inline...
On Dec 19, 2014,
On Sat, Dec 20, 2014 at 1:50 PM, Caridy Patino car...@gmail.com wrote:
what make you think this proposal implies blocking?
I think he was reading your examples using require() and thinking you
were suggesting that the semantics would match.
- Matthew Robb
On Sat, Dec 20, 2014 at 10:54 AM, Matthew Robb matthewwr...@gmail.com
wrote:
On Sat, Dec 20, 2014 at 1:50 PM, Caridy Patino car...@gmail.com wrote:
what make you think this proposal implies blocking?
I think he was reading your examples using require() and thinking you
were suggesting
John, think of script defer src=mod.js/script.
For script type=module, async is implicit.
Sent from my iPhone
On Dec 20, 2014, at 3:01 PM, John Barton johnjbar...@google.com wrote:
On Sat, Dec 20, 2014 at 10:54 AM, Matthew Robb matthewwr...@gmail.com
wrote:
On Sat, Dec 20, 2014 at
Thank you both.
Looking forward to the feedback.
On Fri, Dec 19, 2014 at 6:55 PM, Rick Waldron waldron.r...@gmail.com
wrote:
Done: https://github.com/tc39/agendas/blob/master/2015/01.md
On Fri Dec 19 2014 at 12:26:33 PM Jason Orendorff
jason.orendo...@gmail.com wrote:
Having said that, I
On Dec 20, 2014, at 2:02 PM, Caridy Patino wrote:
John, think of script defer src=mod.js/script.
For script type=module, async is implicit.
What if you have a series of modules that need to be evaluated in sequential
order? (Remember, that a module with no imports is the module worlds
The problem is that those inline modules might import other modules, e.g.:
script type=module
import foo from ./foo.js;
window.sequence = 10;
console.log(window.sequence);
/script
script type=module
console.log( should be 11: + ++window.sequence);
/script
IMO they should be async
IMO order should always be preserved.
From: Caridy Patinomailto:car...@gmail.com
Sent: 2014-12-20 21:21
To: Allen Wirfs-Brockmailto:al...@wirfs-brock.com
Cc: es-discuss listmailto:es-discuss@mozilla.org
Subject: Re: Any news about the `module` element?
The
I don't think it's a problem though. As long as the private Symbol doesn't
leak, there is no way to access private properties. Private Symbol as I
supposed only eliminate itself from getOwnPropertySymbols, and that's
it,nbsp;there should not be no morenbsp;constraintsnbsp;on private
Oops, seems Outlook.com ruins my email. One more time
I don't think it's a problem though. As long as the private Symbol doesn't
leak, there is no way to access private properties. Private Symbol as I
supposed only eliminate itself from getOwnPropertySymbols, and that's it, there
should not
Did you read the linked post? The problem is completely different from the one
you describe. It is about interoperability with membranes.
From: Gary Guomailto:nbdd0...@hotmail.com
Sent: 2014-12-20 21:41
To: es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
One link there are 4 assumptions about private symbol, while I think the
existence of first one is sufficient.
1. They would not be discoverable by Object.getOwnPropertySymbols
This is what I suggest.
2. They would not invoke any traps on proxies.
3. They would not tunnel through proxies to
Under careful use of the symbols, and without Object.getOwnPropertySymbols
leaking every symbol, we can use symbols as private field.
There are other ways that symbols can leak besides
`getOwnPropertySymbols`. Take a look at proxies, which allow you to
intercept [[Get]] and [[Set]].
In
2. They would not invoke any traps on proxies.
3. They would not tunnel through proxies to proxy targets.
4. Getting a private-symbol-keyed property would not traverse the
prototype chain of the object (perhaps arguable).
Unnecessary, as long as symbol doesn't leak to external environment, I
Technically speaking there is no way to prevent such a attack, since in the
debugger everything can be exposed to external environment. Careful check is
still needed with private symbols according to my proposal.
```js
var constructor=function(){
'use strict';
var sym=Symbol('private',
Oops, mistakes found. I just ignored the fact that in this particular way the
Symbol can be retrieved. It seems impossible to have an idea of private symbol
in this way. In the case, I think the language can provide a way to distinguish
whether an object is created directly by a
21 matches
Mail list logo
