Re: Object.assign()

On Oct 17, 2012, at 9:34 PM, Axel Rauschmayer wrote: >> Pardon, I missed and cannot find what is Object.assign(...), seems it's not >> from the latest draft. Is it just defining properties (via >> Object.defineProperty) on from a source to destination object? Like old-good >> Object.extend(...

Re: Object.assign()

> Pardon, I missed and cannot find what is Object.assign(...), seems it's not > from the latest draft. Is it just defining properties (via > Object.defineProperty) on from a source to destination object? Like old-good > Object.extend(...)? Explained here: https://github.com/rwldrn/tc39-notes/b

Re: Object.assign()

On Oct 17, 2012, at 8:32 PM, Rick Waldron wrote: > On Wednesday, October 17, 2012 at 11:18 PM, Axel Rauschmayer wrote: >>> I've always viewed enumerability as an implied intent of sharing. Copying >>> non-enumerable properties is a violation of my expectations (I assure you, >>> I'm not alone) >

Re: Object.assign()

On Wednesday, October 17, 2012 at 11:18 PM, Axel Rauschmayer wrote: > > I've always viewed enumerability as an implied intent of sharing. Copying > > non-enumerable properties is a violation of my expectations (I assure you, > > I'm not alone) > > > That is an interesting point. Does the preven

Re: Object.assign()

> I've always viewed enumerability as an implied intent of sharing. Copying > non-enumerable properties is a violation of my expectations (I assure you, > I'm not alone) That is an interesting point. Does the prevention of sharing ever occur in practice (apart from hiding the methods of built-i

Re: Object.assign()

On Wednesday, October 17, 2012 at 10:53 PM, Axel Rauschmayer wrote: > Addendum: For example, you won’t be able to reliably use Object.assign() to > mix an object with methods into a prototype object, because those methods > might be non-enumerable. > This not a silver bullet by any means. If

Re: Object.assign()

On Wednesday, October 17, 2012 at 10:47 PM, Axel Rauschmayer wrote: > > > On Wednesday, October 17, 2012 at 10:27 PM, Axel Rauschmayer wrote: > > > > I’m a bit skeptical about excluding non-enumerable properties for > > > > Object.assign(). I still find enumerability a hard concept to wrap my > >

Re: Object.assign()

Addendum: For example, you won’t be able to reliably use Object.assign() to mix an object with methods into a prototype object, because those methods might be non-enumerable. I think I initially misunderstood you. You think that what I’ve mentioned above is a feature, I’d argue that it is a bug

Re: Object.assign()

>> On Wednesday, October 17, 2012 at 10:27 PM, Axel Rauschmayer wrote: >>> I’m a bit skeptical about excluding non-enumerable properties for >>> Object.assign(). I still find enumerability a hard concept to wrap my mind >>> around, because it pops up in unexpected places. At the moment, it mostly

Re: Object.assign()

On Wednesday, October 17, 2012 at 10:34 PM, Rick Waldron wrote: > On Wednesday, October 17, 2012 at 10:27 PM, Axel Rauschmayer wrote: > > I’m a bit skeptical about excluding non-enumerable properties for > > Object.assign(). I still find enumerability a hard concept to wrap my mind > > around, be

Re: Object.assign()

On Wednesday, October 17, 2012 at 10:27 PM, Axel Rauschmayer wrote: > I’m a bit skeptical about excluding non-enumerable properties for > Object.assign(). I still find enumerability a hard concept to wrap my mind > around, because it pops up in unexpected places. At the moment, it mostly > matte

Object.assign()

I’m a bit skeptical about excluding non-enumerable properties for Object.assign(). I still find enumerability a hard concept to wrap my mind around, because it pops up in unexpected places. At the moment, it mostly matters for for...in and Object.keys()/Object.getOwnPropertyNames(). Does it rea

RE: Modules, Concatenation, and Better Solutions

From: Patrick Mueller > On Wed, Oct 17, 2012 at 5:04 PM, Russell Leggett > wrote: >>     module "a.js" { >>        import b from "b.js"; >>        console.log("a"); >>        export let a = "a"; >>    } >>    module "b.js" { >>        console.log("b"); >>        export let b = "b"; >>    }      >

Re: Modules, Concatenation, and Better Solutions

> I think we all agree that concatenation is not going away. In principle, > it's the concatenator's fault if they do a non-semantics-preserving > transformation. In practice, if getting the semantics-preserving > transformation right is too hard, people will get it wrong, and it's our > fault for

Re: Modules, Concatenation, and Better Solutions

On Wed, Oct 17, 2012 at 5:04 PM, Russell Leggett wrote: > module "a.js" { > import b from "b.js"; > console.log("a"); > export let a = "a"; > } > module "b.js" { > console.log("b"); > export let b = "b"; > } > > //main.js > import a f

Re: Modules, Concatenation, and Better Solutions

I think we all agree that concatenation is not going away. In principle, it's the concatenator's fault if they do a non-semantics-preserving transformation. In practice, if getting the semantics-preserving transformation right is too hard, people will get it wrong, and it's our fault for making

Re: Modules, Concatenation, and Better Solutions

Maybe this is already obvious, but if modules are tightly coupled to files then the concatenation really has to be a container of files (eg zip) and it's not part of the language. If multiple modules can be declared in a single file, then concatenation is part of the language and has to work whethe

Re: Modules, Concatenation, and Better Solutions

On Oct 17, 2012, at 2:04 PM, Russell Leggett wrote: > I'm not sure if I like how this is turning out. I think modules should either > not allow side effects, or should be evaluated immediately like an IIFE. > While I appreciate lazy evaluation when it is really utilized like Haskell, I > think

Re: Modules, Concatenation, and Better Solutions

On Wed, Oct 17, 2012 at 1:59 PM, Kevin Smith wrote: > > So any reference to A (not necessarily dotted) in the outer module >> triggers hoisted initialization of A? And if no such reference exists >> module A is essentially deal code? >> > > So side-effects would be allowed by the language, but

Re: [Fwd: Fail-fast on non-existing [[Get]]]

On Wed, Oct 17, 2012 at 2:55 PM, Brendan Eich wrote: > Tom Van Cutsem wrote: > >> 2012/10/16 Herby Vojčík mailto:he...@mailbox.sk>> >> >> >> I see two solutions: >> - add something to the freeze, seal, preventExtensions family which >> would set an object to the fail-fast [[Get]] st

Re: [Fwd: Fail-fast on non-existing [[Get]]]

Tom Van Cutsem wrote: 2012/10/16 Herby Vojčík mailto:he...@mailbox.sk>> I see two solutions: - add something to the freeze, seal, preventExtensions family which would set an object to the fail-fast [[Get]] state. - use a Proxy in the proto chain to trap the unknown [[Get]] an

Re: [Fwd: Fail-fast on non-existing [[Get]]]

2012/10/16 Herby Vojčík > I see two solutions: > - add something to the freeze, seal, preventExtensions family which > would set an object to the fail-fast [[Get]] state. > - use a Proxy in the proto chain to trap the unknown [[Get]] and > throw early > > Do you think this needs a solution at

Re: Modules, Concatenation, and Better Solutions

> So any reference to A (not necessarily dotted) in the outer module > triggers hoisted initialization of A? And if no such reference exists > module A is essentially deal code? > So side-effects would be allowed by the language, but would be incredibly confounding. Hmmm Kevin

Re: Modules, Concatenation, and Better Solutions

On Oct 17, 2012, at 9:43 AM, Sam Tobin-Hochstadt wrote: > On Wed, Oct 17, 2012 at 12:40 PM, Allen Wirfs-Brock > wrote: >> >> On Oct 17, 2012, at 9:09 AM, Sam Tobin-Hochstadt wrote: >> >>> On Wed, Oct 17, 2012 at 9:51 AM, Kevin Smith wrote: > Do we log "you need me" only when f is ca

Re: Modules, Concatenation, and Better Solutions

On Wed, Oct 17, 2012 at 12:40 PM, Allen Wirfs-Brock wrote: > > On Oct 17, 2012, at 9:09 AM, Sam Tobin-Hochstadt wrote: > >> On Wed, Oct 17, 2012 at 9:51 AM, Kevin Smith wrote: >>> Do we log "you need me" only when f is called for the first time? >>> >>> >>> Sorry - that makes no sense. What

Re: Modules, Concatenation, and Better Solutions

On Oct 17, 2012, at 9:09 AM, Sam Tobin-Hochstadt wrote: > On Wed, Oct 17, 2012 at 9:51 AM, Kevin Smith wrote: >> >>> Do we log "you need me" only when f is called for the first time? >> >> >> Sorry - that makes no sense. What I meant was: >> >>module A { >> console.log("you need me

Re: Modules, Concatenation, and Better Solutions

On Wed, Oct 17, 2012 at 9:51 AM, Kevin Smith wrote: > >> Do we log "you need me" only when f is called for the first time? > > > Sorry - that makes no sense. What I meant was: > > module A { > console.log("you need me"); > export var x = "x"; > } > > export function f() {

Re: ES accessor usage guidelines (Was: Map/Set.prototype.size)

On Wed, Oct 17, 2012 at 11:16 AM, Mark S. Miller wrote: > On Tue, Oct 16, 2012 at 4:06 PM, Yehuda Katz wrote: > >> On Tue, Oct 16, 2012 at 6:26 PM, Mark S. Miller wrote: >> >>> Getting the comments with a getter seems fine. Appending only the list >>> of comments with a setter is bad, as it does

Re: Modules, Concatenation, and Better Solutions

On Tue, Oct 16, 2012 at 10:10 PM, David Herman wrote: > On Oct 16, 2012, at 4:51 PM, John J Barton > wrote: > >> On Tue, Oct 16, 2012 at 2:58 PM, David Herman wrote: >>> The weird thing about (a) is that code that appears to be straight-line >>> actually executes in somewhat more unpredictable

Re: Modules, Concatenation, and Better Solutions

Kevin Smith wrote: Do we log "you need me" only when f is called for the first time? Sorry - that makes no sense. What I meant was: module A { console.log("you need me"); export var x = "x"; } export function f() { console.log(A.x); } Do we log "you nee

Re: ES accessor usage guidelines (Was: Map/Set.prototype.size)

On Tue, Oct 16, 2012 at 4:06 PM, Yehuda Katz wrote: > On Tue, Oct 16, 2012 at 6:26 PM, Mark S. Miller wrote: > >> Getting the comments with a getter seems fine. Appending only the list of >> comments with a setter is bad, as it does not resemble storage semantics. > > > Do you mean appending only

Re: ES accessor usage guidelines (Was: Map/Set.prototype.size)

I agree (unsurprisingly) with Arv and Yehuda on this. Side effects are what make the world go 'round. Getting overly prescriptive here is just a way to box us into [not]using some particular stylistic form when designing API...and I don't see how that settles any interesting questions. I'd much rat

Re: Modules, Concatenation, and Better Solutions

> Do we log "you need me" only when f is called for the first time? > Sorry - that makes no sense. What I meant was: module A { console.log("you need me"); export var x = "x"; } export function f() { console.log(A.x); } Do we log "you need me" only when f is c

Re: Modules, Concatenation, and Better Solutions

> Browsers can load from ZIP files, some even supported the .jar variant and > http://some.site.com/big.jar!**membernotation > (not sure what's still working there). But this is again > multiplying risks. Will developers all ZIP this way, instead of using TE >

Re: Modules, Concatenation, and Better Solutions

Kevin Smith wrote: Concating source files has always been a suboptimal solution to the multiple request problem anyway. It's not as cringe-inducing as image sprites, but it's up there. As David Bruant mentioned, a design goal for HTTP 2 is to make such spriting unnecessary. Will HTTP 2 perme

Re: Modules, Concatenation, and Better Solutions

> I see two coherent alternatives: > > (a) execute inline modules by need (i.e., on first import) rather than > eagerly > (b) execute external modules "transactionally", trying to order them by > dependency so that imported modules have fully initialized before the code > that depends on them runs

Re: [Fwd: Fail-fast on non-existing [[Get]]]

Yehuda Katz wrote: Yehuda Katz (ph) 718.877.1325 On Tue, Oct 16, 2012 at 12:51 PM, Herby Vojčík mailto:he...@mailbox.sk>> wrote: This did not get to the list, reposting... Original Message From: Herby Vojčík mailto:he...@mailbox.sk>> Subject: Fail-fast on

Re: Modules, Concatenation, and Better Solutions

On the one hand, the point of eager execution was to make the execution model simple and consistent with corresponding IIFE code. When we switch from scripts to modules, it makes sense to switch from execute-as-encountered-for-side-effect to resolve-dependencies- and-extract-exports. The former