Thanks for your answers.
Object.assign seems good but provides only copy for enumerable
properties, not a real deep clone.
I know for jquery, that's why i precised only for DOM but it was
just to show the syntax :)
2014-06-11 0:00 GMT+02:00 Rick Waldron waldron.r...@gmail.com:
On Tue, Jun
Hi Maxime,
Good to see you here :-)
This topic has been discussed recently on Twitter. See
https://twitter.com/jeremyckahn/status/474259042005553154
I'm like Rick's answer in particular
https://twitter.com/rwaldron/status/475017360085364736
as I believe a large share of cloning is just about
Hi David :)
thanks for the links !
You are right, it's generally about data. Serialize an object to JSON
prevent from sharing references. On the twitter feed Jeremy talks
about optimizing the process . I'm agree with that, for performance
and a nicer syntax.
By the way, the Object.deepFreeze is
On Wednesday, June 11, 2014, Maxime Warnier mar...@gmail.com wrote:
Thanks for your answers.
Object.assign seems good but provides only copy for enumerable
properties, not a real deep clone.
I know for jquery, that's why i precised only for DOM but it was
just to show the syntax :)
Oops,
A variety of places in the spec use the new IsConstructor abstract operation.
In ES5, this test (essentially, does the object implement the [[Construct]]
internal method) was restricted to the `new` operator. But in ES6, it is used
in implementing a large variety of built-in functions:
- All
I really just want single exports and destructuring of single exports...??
I would second that. I have seen no desire for any static analysis beyond
this module depends on that module and I've seen no desire for live bound
imports.
I accept that we're messing with a fragile consensus, but
Another way of thinking of IsConstructor is whether the function has an own
prototype property or not. The only exception[*] there is bound functions
where one would need to know if the [[TargetFunction]] IsConstructor or not.
[*] Proxies are oddballs here. All Proxies have a [[Construct]] method
[*] Proxies are oddballs here. All Proxies have a [[Construct]] method so
the IsConstructor will always return true which is really not what you
want. If IsConstructor was changed to check for a .prototype instead
proxies would behave more inline with ordinary objects.
[[Construct]] is only
On Wed, Jun 11, 2014 at 10:24 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
A variety of places in the spec use the new IsConstructor abstract
operation. In ES5, this test (essentially, does the object implement the
[[Construct]] internal method) was restricted to the `new`
Quick note: that isConstructor isn't really viable unless you plan on using
it with constructors that do not have side effects.
Rick
On Wed, Jun 11, 2014 at 10:58 AM, Rick Waldron waldron.r...@gmail.com
wrote:
On Wed, Jun 11, 2014 at 10:24 AM, Domenic Denicola
dome...@domenicdenicola.com
On Wed, Jun 11, 2014 at 11:05 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/11/14, 10:58 AM, Rick Waldron wrote:
function isConstructor(C) {
try {
new C();
This will fail for constructors that require actual arguments, right?
This, as well as the other warning I posted.
Rick
According to paragraph 11.4.1 of ECMA262 v.5.1, and in particular to
point 5.a of that paragraph, a catchable SyntaxError exception should
be thrown when deleting a strict reference in strict mode. The code
below tests this feature:
var fun = function (){
use strict; // strict mode
delete
Quick note: that isConstructor isn't really viable unless you plan on using
it with constructors that do not have side effects.
Rick
The Proxy-based solution needs to be used in these cases. Now we just
need to wait until Proxies are available everywhere! ;-)
On Wed, Jun 11, 2014 at
On 6/11/14, 11:08 AM, Sergio Maffeis wrote:
According to paragraph 11.4.1 of ECMA262 v.5.1, and in particular to
point 5.a of that paragraph, a catchable SyntaxError exception should
be thrown when deleting a strict reference in strict mode.
...
We found that current browsers instead terminate
2014-06-11 16:48 GMT+02:00 Erik Arvidsson erik.arvids...@gmail.com:
[*] Proxies are oddballs here. All Proxies have a [[Construct]] method so
the IsConstructor will always return true which is really not what you
want. If IsConstructor was changed to check for a .prototype instead
proxies
On 6/11/14, 10:58 AM, Rick Waldron wrote:
function isConstructor(C) {
try {
new C();
This will fail for constructors that require actual arguments, right?
For example, this will fail if C === window.Worker in a browser.
-Boris
___
On Wed, Jun 11, 2014 at 11:05 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/11/14, 10:58 AM, Rick Waldron wrote:
function isConstructor(C) {
try {
new C();
This will fail for constructors that require actual arguments, right?
For example, this will fail if C === window.Worker in
On 11 juin 2014, at 17:11, André Bargull andre.barg...@udo.edu wrote:
Quick note: that isConstructor isn't really viable unless you plan on using
it with constructors that do not have side effects.
Rick
The Proxy-based solution needs to be used in these cases. Now we just need to
wait
On 6/11/2014 5:40 PM, Alexandre Morgaut wrote:
On 11 juin 2014, at 17:11, André Bargull andre.barg...@udo.edu wrote:
Quick note: that isConstructor isn't really viable unless you plan on using
it with constructors that do not have side effects.
Rick
The Proxy-based solution needs to be
On Jun 11, 2014, at 8:16 AM, Tom Van Cutsem wrote:
2014-06-11 16:48 GMT+02:00 Erik Arvidsson erik.arvids...@gmail.com:
[*] Proxies are oddballs here. All Proxies have a [[Construct]] method so the
IsConstructor will always return true which is really not what you want. If
IsConstructor
On Jun 11, 2014, at 8:49 AM, André Bargull wrote:
From [1]:
```javascript
function IsConstructor(o) {
try {
new (new Proxy(o, {construct: () = ({})}));
return true;
} catch(e) {
return false;
}
}
```
This IsConstructor implementation does not trigger any side-effects
# June 4 2014 Meeting Notes
Brian Terleson (BT), Dmitry Lomov (DL), Waldemar Horwat (WH), Allen
Wirfs-Brock (AWB), John Neumann (JN), Rick Waldron (RW), Eric Ferraiuolo
(EF), Jafar Husain (JH), Jeff Morrison (JM), Mark Honenberg (MH), Caridy
Patino (CP), Yehuda Katz (YK), Niko Matsakis (NM), Ben
# June 5 2014 Meeting Notes
Brian Terleson (BT), Dmitry Lomov (DL), Waldemar Horwat (WH), Allen
Wirfs-Brock (AWB), John Neumann (JN), Rick Waldron (RW), Eric Ferraiuolo
(EF), Jafar Husain (JH), Jeff Morrison (JM), Mark Honenberg (MH), Caridy
Patino (CP), Yehuda Katz (YK), Niko Matsakis (NM), Ben
# June 6 2014 Meeting Notes
Brian Terleson (BT), Dmitry Lomov (DL), Waldemar Horwat (WH), Allen
Wirfs-Brock (AWB), John Neumann (JN), Rick Waldron (RW), Eric Ferraiuolo
(EF), Jafar Husain (JH), Jeff Morrison (JM), Mark Honenberg (MH), Caridy
Patino (CP), Yehuda Katz (YK), Niko Matsakis (NM), Ben
Expanded Conclusion/Resolution for the ArrayBuffer neutering discussion:
## Conclusion/Resolution
- Don't add isNeutered yet, and expect clients use try-catch when accessing
properties to determine status.
- Also remember to change the name. Released? Vacated?
- Any attempt to access (read or
On Jun 11, 2014, at 7:24 AM, Domenic Denicola wrote:
A variety of places in the spec use the new IsConstructor abstract operation.
In ES5, this test (essentially, does the object implement the [[Construct]]
internal method) was restricted to the `new` operator. But in ES6, it is
used in
On Wed, Jun 11, 2014 at 12:44 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Array.from and Array.of have a non-throwing IsConstrutor test because they
are designed to allow things like this:
let of = Array.of;
of(1,2,3,4,5); //Equivalent to: Array.of(1,2,3,4,5)
I don't recall why we
On 11 June 2014 18:44, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Other than the Array.of and Array.from usages the other uses are all
necessary either functionally (you can't just try to construct by calling
[[Construct]], it requires an explicit guard) or to deal with special
On Wed, Jun 11, 2014 at 12:44 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jun 11, 2014, at 7:24 AM, Domenic Denicola wrote:
A variety of places in the spec use the new IsConstructor abstract
operation. In ES5, this test (essentially, does the object implement the
[[Construct]]
Saving 12 bytes does not seem like an obvious end-programmer benefit
to me. It seems like unnecessary and premature optimization.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
It's also deceptive: it makes you think `Array.of` and `Array.from` are
functions, when in reality they are definitely methods.
From: es-discuss es-discuss-boun...@mozilla.org on behalf of C. Scott Ananian
ecmascr...@cscott.net
Sent: Wednesday, June 11,
2014-06-11 18:02 GMT+02:00 Allen Wirfs-Brock al...@wirfs-brock.com:
Kind of boarder line. 6.1.7.2 says that the essential internal methods
are those listed in Table 5 (does not include [[Call]] and
[[Constructor]]). Also the definitions of [[Call]] and [[Construct]] in
9.5 each include a
On Jun 10, 2014, at 9:35 PM, Ian Hickson wrote:
On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote:
No, that's not the intent of the ES design. The EnqueueTask abstract
operations takes the name of a specific Job queue as an argument and
always places the newly created PendingJob record into
I may still try to tighten up the language. I usually consider even one person
being uncertain about the meaning of some prose in the spec. to be an
indication that others will probably also be confused.
Allen
On Jun 11, 2014, at 10:49 AM, Tom Van Cutsem wrote:
2014-06-11 18:02 GMT+02:00
From: Allen Wirfs-Brock al...@wirfs-brock.com
There are a few uses of IsConstructor in some Array methods that deal with
subtle backwards compat issues that are a result of extending Array to be
subclassable. These are very unique cases and I don't think you should look
at them as
On Jun 11, 2014, at 11:09 AM, Domenic Denicola wrote:
From: Allen Wirfs-Brock al...@wirfs-brock.com
There are a few uses of IsConstructor in some Array methods that deal with
subtle backwards compat issues that are a result of extending Array to be
subclassable. These are very unique
On Wed, Jun 11, 2014 at 1:37 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
It's also deceptive: it makes you think `Array.of` and `Array.from` are
functions, when in reality they are definitely methods.
Yes, you're right.
What about Array subclasses? `from` and `of` are inherited
From: Rick Waldron waldron.r...@gmail.com
Or maybe that's not necessary? Is it preferable to just throw when someone
writes any of these:
I think it is indeed preferable, as would happen when using any other method
(`this`-dependent function) without a `this`.
(Note that `Array.isArray`
I would second that. I have seen no desire for any static analysis beyond
this module depends on that module and I've seen no desire for live bound
imports.
I believe that viewpoint is adequately represented in the status quo. No
need to legislate other viewpoints away.
I accept that
On Wed, Jun 11, 2014 at 3:27 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Of course this can all be fixed with .bind() or a bind operator, but it
just seems unfortunate to throw out something that's not harming the spec in
favor something that might be problematic in end user
On Wed, Jun 11, 2014 at 3:41 PM, Kevin Smith zenpars...@gmail.com wrote:
Well, you're assuming exactly the state of affairs that this thread is
questioning... The fact that the threat of changing things to this degree
has dredged up such polarized opinions should indicate that we ought to be
On Jun 11, 2014, at 11:59 AM, Rick Waldron wrote:
On Wed, Jun 11, 2014 at 1:37 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
It's also deceptive: it makes you think `Array.of` and `Array.from` are
functions, when in reality they are definitely methods.
Yes, you're right.
On Wed, Jun 11, 2014 at 3:27 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: Rick Waldron waldron.r...@gmail.com
Or maybe that's not necessary? Is it preferable to just throw when
someone writes any of these:
I think it is indeed preferable, as would happen when using any
On Wed, Jun 11, 2014 at 4:04 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jun 11, 2014, at 11:59 AM, Rick Waldron wrote:
On Wed, Jun 11, 2014 at 1:37 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
It's also deceptive: it makes you think `Array.of` and `Array.from` are
I have been working extensively with modules in a project that will be
going live this year. I am using traceur and I find myself often doing the
following:
module fs from fs;
var { readFile } = fs;
OR
import { readFile as _readFile } from fs;
var
readFile = _readFile;
It's
Hi,
It's probably too late to raise an objection, but anyway.
I've tried to find out the rational for the import [...] from [...]
syntax (rather than the common from [...] import [...]), and only found
the following old thread :
http://esdiscuss.org/topic/simpler-sweeter-syntax-for-modules,
From: es-discuss es-discuss-boun...@mozilla.org on behalf of Matthew Robb
matthewwr...@gmail.com
Transpile aside, I don't want that performance concern. Most of the time I
want a real solid reference and the only way to get it as the spec stands is
to import something and then cache it
On Wed, Jun 11, 2014 at 4:39 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: es-discuss es-discuss-boun...@mozilla.org on behalf of Matthew Robb
matthewwr...@gmail.com
Transpile aside, I don't want that performance concern. Most of the time I
want a real solid reference and
The Traceur project would be interested in your issues and in a discussion
on how to improve. Improvements are easy to try.
jjb
On Wed, Jun 11, 2014 at 1:25 PM, Matthew Robb matthewwr...@gmail.com
wrote:
I have been working extensively with modules in a project that will be
going live this
On Wed, Jun 11, 2014 at 1:53 PM, John Barton johnjbar...@google.com wrote:
The Traceur project would be interested in your issues and in a discussion
on how to improve. Improvements are easy to try.
jjb
No matter what improvements could be made you are always going to have a
slower, less
On 11 June 2014 14:01, Matthew Robb matthewwr...@gmail.com wrote:
On Wed, Jun 11, 2014 at 1:53 PM, John Barton johnjbar...@google.com
wrote:
The Traceur project would be interested in your issues and in a
discussion on how to improve. Improvements are easy to try.
jjb
No matter what
Everyone just needs to chill out - ES6 modules are well-designed (thanks to
Sam and Dave and Andreas and maybe myself a little ; ) and they are going
to work extremely well in the field.
The message needs to be that modules are *done*. Period. (Minus some
minor cosmetic issues, perhaps.)
Kevin, although I agree that ES6 modules are well-designed, I don't think
the checkpoint that we did last week was a mistake, in fact, we invited
implementers of the polyfills and transpilers to share their concerns and
questions, to help us to correct course, that's all it was.
Saying that the
I think I was still using tabs when I've written a semantic import that
used from upfront [1]
However, it depends how you look at your imports ... when you read
import { _ } from
import { $ } from
import { gzip } from
you realize you don't even need to know where does that come from since the
Thanks Caridy,
Please forgive my occasional hyperbole, I think es-discuss is best served
with a dash of spice now and then. : )
I agree that the current design is somewhat confusing. That's because it
represents a perfectly balanced compromise between the multi-export,
remote-binding design
For anyone interested in the transpiler story around the existing spec I
opened an issue here: https://github.com/google/traceur-compiler/issues/1072
- Matthew Robb
On Wed, Jun 11, 2014 at 5:43 PM, Kevin Smith zenpars...@gmail.com wrote:
Thanks Caridy,
Please forgive my occasional
56 matches
Mail list logo
