Re: Name-spaced cross-realm objects

strike a middle ground between global and > name-spaced; That is the ability to create/access your own name-spaced > state similar to Symbol.for. As an example – a name-spaced incrementing > number: > > // a.js > const fn = UID.for('namespace') > > assert(fn() === 0) >

Name-spaced cross-realm objects

middle ground between global and name-spaced; That is the ability to create/access your own name-spaced state similar to Symbol.for. As an example – a name-spaced incrementing number: // a.js const fn = UID.for('namespace') assert(fn() === 0) assert(fn() === 1) // b.js const fn = UID.for('namespace

Re: Allowing object field name shorthand

(Sorry, just seeing this as it went to my spam folder - Ron, Google claims it "failed microsoft.com extra verification" or something like that.) > In this example, the actual name for the property is the rightmost > identifier of the expression. This differs from the proposa

RE: Allowing object field name shorthand

tle, x.category.categoryName })); // creates: [{ isbn: 123456789, title: “…”, categoryName: “…” }, …] ``` In this example, the actual name for the property is the rightmost identifier of the expression. This differs from the proposal at the start of this thread, but may also be worth considering. Ron (My apolog

Re: Allowing object field name shorthand

Another -1 for this. It adds complexity to object initializer processing, both in the obvious way (has to figure out to create the hidden object or possibly several nested hidden objects), and around the fact that object initializers are processed in source code order. Exactly, this proposal

Re: Allowing object field name shorthand

I also vote against this. A further problem could be duplication of field names in large objects. Imagine there is a field2.field3.field4.field5 in the beginning of your object and then another one 100 lines below. Using the currently well defined way to define nested objects at least groups

Re: Allowing object field name shorthand

I don't see how this is like referencing the object a field is in during object construction. Yes field2.field4 would not be able to reference field2.field3 but that is not what I am proposing. I am proposing a syntactic sugar for nested objects On 2017-06-22 10:05 PM, J Decker wrote: On

Re: Allowing object field name shorthand

On Thu, Jun 22, 2017 at 7:56 AM, Sebastian Malton wrote: > I would like to propose that the dot or '.' is allowed in object field > names so that the following are allowed. > > var obj = { > field1: "val" , > field2.field3: 3, > field2.field4: true > }; > >

Re: Allowing object field name shorthand

it's already valid syntax, then why suggest it mean something > else? Breaking changes require **extremely compelling** justification (and > new language modes, à la strict mode, which I don't think there's any > appetite for at present). > > I'm still not seeing any solid benefits to re

Re: Allowing object field name shorthand

the top-level field name. I'll step back at this point, I've raised the issues / concerns that came to me. Best, -- T.J. Crowder On Thu, Jun 22, 2017 at 6:25 PM, Sebastian Malton <sebast...@malton.name> wrote: > Okay, I know that "a.b" is already valid syntax but wi

Re: Allowing object field name shorthand

: June 22, 2017 1:14 PMTo: sebast...@malton.nameCc: es-discuss@mozilla.orgSubject: Re: Allowing object field name shorthand On Thu, Jun 22, 2017 at 5:53 PM, Sebastian Malton <sebast...@malton.name> wrote: I would say that the easiest benefit would be the shorthand.But as I pointed out, it

Re: Allowing object field name shorthand

if the main property name is just one character; at two characters, it's a tie; and from three characters it's *less* concise. From three properties onward it's less concise even with a single-character top-level name: ```js // One property let o = {ex: {b: 1}}; // Current let

Re: Allowing object field name shorthand

On Thu, Jun 22, 2017 at 10:23 PM, Sebastian Malton wrote: > In my opinion the notation of {"n.b": 1} should equate to {n.b: 1} so that > object field retrieval is consistent. That's a hugely breaking change. ___ es-discuss

Re: Allowing object field name shorthand

w...@farsightsoftware.comSent: June 22, 2017 11:52 AMTo: sebast...@malton.nameCc: es-discuss@mozilla.orgSubject: Re: Allowing object field name shorthand Can you expand on the benefits vs. costs (e.g., complexity, clarity)?I ask because I'm not immediately seeing a lot of benefit, but I'm seeing vario

Re: Allowing object field name shorthand

{ > field1: "val" , > field2: { > field3: 3, > field4: true > } > }; > > and even > > var obj.name = "Hello" ; > > would become > > var obj = { > name: "Hello" > }; > > > Sebastian >

Allowing object field name shorthand

        field4: true    }};and evenvar obj.name = "Hello" ;would become var obj = {    name: "Hello" };Sebastian  __

Infer name of anonymous callback function based on argument name

As of ES2015 functions defined without an explicit name get their name from the variable or property they are assigned to, which is great for debugging. I want to propose another way a function can get it's name, which is when anonymous functions (or arrow functions) are defined as parameter

Re: name anonymous functions on property assignments

> I fixed it by putting the function inside `Object()` You can also use the comma operator: ```js var anon = (0, function () {}); anon.name; // "" ``` ;Oriol ___ es-discuss mailing list es-discuss@mozilla.org

Re: name anonymous functions on property assignments

://github.com/ljharb/function.prototype.name/blob/master/test/tests.js#L7-L9 but that wouldn't be necessary without function name inference. On Sat, Jan 28, 2017 at 8:11 AM, T.J. Crowder < tj.crow...@farsightsoftware.com> wrote: > On Sat, Jan 28, 2017 at 3:46 PM, Allen Wirfs-Brock > <al...@

Re: name anonymous functions on property assignments

On Sat, Jan 28, 2017 at 3:46 PM, Allen Wirfs-Brock <al...@wirfs-brock.com> wrote: > > > > On Jan 27, 2017, at 7:26 AM, T.J. Crowder <tj.crow...@farsightsoftware.com> > > wrote: > > > > Two questions on the minor issue of the following not assigning

Re: name anonymous functions on property assignments

> On Jan 27, 2017, at 7:26 AM, T.J. Crowder <tj.crow...@farsightsoftware.com> > wrote: > > Two questions on the minor issue of the following not assigning a name > to the function: > > ```js > obj.foo = function() { }; > ``` > > 1) Am I correct that th

Re: name anonymous functions on property assignments

Just for a bit of context, can you elaborate on how this broke your code? Thanks On 27 January 2017 at 16:56, Jordan Harband <ljh...@gmail.com> wrote: > I'd have an objection. Function name inference has already broken my code > - luckily only tests so far, that i know of - and d

Re: name anonymous functions on property assignments

On Fri, Jan 27, 2017 at 4:56 PM, Jordan Harband <ljh...@gmail.com> wrote: > I'd have an objection. Function name inference has already broken my code - > luckily only tests so far, that i know of - and doing it more often would > break more of it. :-) Sorry to hear that. The

Re: name anonymous functions on property assignments

I'd have an objection. Function name inference has already broken my code - luckily only tests so far, that i know of - and doing it more often would break more of it. On Fri, Jan 27, 2017 at 7:26 AM, T.J. Crowder < tj.crow...@farsightsoftware.com> wrote: > Two questions on the mi

Re: name anonymous functions on property assignments

Two questions on the minor issue of the following not assigning a name to the function: ```js obj.foo = function() { }; ``` 1) Am I correct that the only reason it doesn't (in spec terms) is that Step 1.e. of [Runtime Semantics: Evaluation](https://tc39.github.io/ecma262/#sec-assignment

Re: name anonymous functions on property assignments

I'm mistaken about Step 1.e of [assignment evaluation][1], it's not that we'd want to remove the IsIdentifierRef check, it's that we'd want to make it "IsIdentifierRef is true or IsPropertyRef is true": > e. If IsAnonymousFunctionDefinition(AssignmentExpression) is true and either >

Re: name anonymous functions on property assignments

/ecma-262/7.0/index.html#sec-assignment-operators-runtime-semantics-evaluation). -- T.J. On Tue, Dec 13, 2016 at 9:03 AM, T.J. Crowder <tj.crow...@farsightsoftware.com> wrote: > About a year ago, Bergi asked[1] why no name is assigned to a function > when it's created as part of a

RE: name anonymous functions on property assignments

About a year ago, Bergi asked[1] why no name is assigned to a function when it's created as part of an assignment to an object property: o.method = () => { }; Allen Wirfs-Brock replied: > We did not have consensus on doing the same for: > `MemberExpression.IdentifierName = FunctionE

The name of Array.prototype.includes

There are two existing methods that are loosely similar to `Array.prototype.includes()`: 1. `String.prototype.includes()` 2. `Set.prototype.has()` Isn’t #2 more similar than #1? Shouldn’t the method be called `Array.prototype.has`, then? -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de

RE: The name of Array.prototype.includes

iscuss@mozilla.org> > Subject: The name of Array.prototype.includes > > There are two existing methods that are loosely similar to > `Array.prototype.includes()`: > > 1. `String.prototype.includes()` > 2. `Set.prototype.has()` > > Isn’t #2 more similar than #1? Shoul

The name of a method whose key is a symbol

This is the behavior defined in the spec: ```js const key1 = Symbol('description'); const key2 = Symbol(); let obj = { [key1]() {}, [key2]() {}, }; console.log(obj[key1].name); // '[description]' console.log(obj[key2].name); // '' ``` I’m wondering: if a symbol has no description

Re: The name of a method whose key is a symbol

being a function name I rather wonder if it wouldn't be better to have `'description'` without square brackets ... to be consistent with the fact the Symbol has no name. If that's instead a way specified as such in order to understand that is a Symbol then I agree, for consistency, it should have

Re: Computed Property Name Shorthand Proposal

Alexander Jones wrote: That's exactly what this is. I appreciate the beauty in symmetry, but I think -1. I second this. On 27 August 2015 at 17:25, Kevin Smith zenpars...@gmail.com mailto:zenpars...@gmail.com wrote: I'd expect the following to work, given that the prop expression

Re: Computed Property Name Shorthand Proposal

That's exactly what this is. I appreciate the beauty in symmetry, but I think -1. On 27 August 2015 at 17:25, Kevin Smith zenpars...@gmail.com wrote: I'd expect the following to work, given that the prop expression evaluates to 'bar', and bar is in context. var foo = 'bar' var bar =

Re: Computed Property Name Shorthand Proposal

I'm usually lousy at interpreting the spec (yet here I go!), but I think the behavior is explained here [1]: PropertyDefinition[Yield] : IdentifierReference[?Yield] CoverInitializedName[?Yield] PropertyName[?Yield] : AssignmentExpression[In, ?Yield] MethodDefinition[?Yield]

Re: Computed Property Name Shorthand Proposal

I'd expect the following to work, given that the prop expression evaluates to 'bar', and bar is in context. var foo = 'bar' var bar = 'ponyfoo' var baz = { [foo] } console.log(baz) // - { bar: 'ponyfoo' } Hmmm... I'm not sure I would expect any such thing. It seems like you're

Computed Property Name Shorthand Proposal

I'd expect the following to work, given that the prop expression evaluates to 'bar', and bar is in context. var foo = 'bar' var bar = 'ponyfoo' var baz = { [foo] } console.log(baz) // - { bar: 'ponyfoo' } The following works var foo = 'bar' var bar = 'ponyfoo' var baz = { [foo]: bar }

Re: name anonymous functions on property assignments

Just saying that an exposed property name is a different (and potentially more broadly exploitable) capability than exposing a local variable name.   TC39 reached consensus on automatically assigning the `name` property for expression forms like:       Identifier = FunctionExpression

Re: name anonymous functions on property assignments

I'm completely against magic-function-name assignment for various reason and leaking ain't one. What are these reasons? (I couldn't find previous discussions; if there are any, a link would be sufficient) I agree that explicit naming is better than implicit, and like to use function

Re: name anonymous functions on property assignments

a big concern for me is what to do about functions being passed around: ``` var a = {}; a.foo = function () {} // .name would be foo var b = {}; b.bar = a.foo; // .name would be bar ``` or ``` function doThing(callback) { var async = {}; async.fn = callback; // ... } doThing

Re: name anonymous functions on property assignments

a big concern for me is what to do about functions being passed around Nothing happens to them. This feature is only about assignments where the right hand side consists of a function expression. var a = {}; a.foo = function () {} // .name would be foo Yes. var b = {}; b.bar = a.foo

Re: name anonymous functions on property assignments

In theory this sounds like a cool idea, I didn't even know variable assignments named functions. The only issue I see here is how we're now differentiating assignment by where it happens - what if the property is computed? As far as I know function names are more constrained (like variable names)

Re: name anonymous functions on property assignments

I just want to point out that Bergus (OP) informed me that the assignment behavior happens in computed object literal keys. So: ```js let o = { [fn + name] () {} } o.fnname.name; // fnname ``` On Sun, Jul 26, 2015 at 10:55 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote

Re: name anonymous functions on property assignments

with all due respect Allen, I'm completely against magic-function-name assignment for various reason and leaking ain't one. What could you assign in ES6 that cannot be retrieved anyway through getOwnPropertySymbols and getOwnPropertyNames ? A triple-magic private Proxy handler or what? I mean

Re: name anonymous functions on property assignments

it sets the function name to a symbol. To make this extra clear - it does Let description be name’s [[Description]] value. and then `defineProperty`s it with that, this is specified in http://www.ecma-international.org/ecma-262/6.0/index.html#sec-setfunctionname On Sun, Jul 26, 2015 at 11:17 PM

Re: name anonymous functions on property assignments

On Jul 26, 2015, at 12:55 PM, Andrea Giammarchi wrote: with all due respect Allen, I'm completely against magic-function-name assignment for various reason and leaking ain't one. Implicit function name property assignment is part of ES2015. What could you assign in ES6 that cannot

Re: name anonymous functions on property assignments

What is the function's name if the computed object literal key is a Symbol? ie, what does the following output: ```js const sym = Symbol('something'); const o = { [sym] () {} }; console.log(o[sym].name); ``` Currently it appears Babel outputs an empty string for this case. If the current

Re: name anonymous functions on property assignments

as I know function names are more constrained (like variable names) in what they can be. Object properties may contain characters that function names may not. the possibility that the property key is a symbol is a primary reason that this expression form does not set the `name` property

Re: name anonymous functions on property assignments

On Jul 26, 2015, at 1:17 PM, Jordan Harband wrote: What is the function's name if the computed object literal key is a Symbol? ie, what does the following output: specified in step 4 of http://ecma-international.org/ecma-262/6.0/#sec-setfunctionname ```js const sym = Symbol('something

name anonymous functions on property assignments

Hello! Currently, unnamed function (and class) definitions that are part of a variable assignment or property definition are automatically given the name of the target identifier (seehttp://www.ecma-international.org/ecma-262/6.0/#sec-assignment-operators-runtime-semantics-evaluation andhttp

Re: Export * as name from source

right, there were a couple of export declaration cases that we missed for ES2015. From the top of my head, I remember `export default from “module”;` which we plan to get on the fast lane for ES2016, ideally they will be spec’d (and in stage 2) by the time vendors start implementing modules :)

Export * as name from source

I’m curious of this history behind this case being missing, I’ve been crawling through the spec and old esdiscuss and can’t find it: I expected the following: export * as someName from module”; To behave much like: Import * as someName from module”; export someName; Except without adding

Re: Function name property

On Sun, Mar 1, 2015 at 4:17 AM Leon Arnott leonarn...@gmail.com wrote: On Sun, Mar 1, 2015 at 3:28 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: If you want both a TCP-able from and a local (most closely enclosing callable thing) form then the later should also presumably also be

Re: Function name property

a problem which is otherwise really hard to express. Actually, another possible name for this that I want to put on the table is: function.last --- the last value passed back via 'next' Allen ___ es-discuss mailing list es-discuss@mozilla.org https

Re: Function name property

On Mar 2, 2015, at 9:22 AM, Rick Waldron wrote: On Sun, Mar 1, 2015 at 4:17 AM Leon Arnott leonarn...@gmail.com wrote: On Sun, Mar 1, 2015 at 3:28 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: If you want both a TCP-able from and a local (most closely enclosing callable thing)

Re: Function name property

On Sun, Mar 1, 2015 at 3:28 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: If you want both a TCP-able from and a local (most closely enclosing callable thing) form then the later should also presumably also be applicable at the top level of functions. The 'in' meta property prefix in

Re: Function name property

Andrea Giammarchi wrote: but how would you drop that listener, if that's even a concern of yours, beside the usage of `function`? I'm not addressing your particular issue just yet -- patience! Does I agree with Mark means already two think arrows function should never be self-reference-able?

Re: Function name property

On Feb 28, 2015, at 9:07 AM, Brendan Eich wrote: No, again, I'm objecting to Allen's just-so story that `function` in an arrow refers to the arrow, and agreeing with Mark that the pellucid meaning (if there is one) would be the TCP one: the enclosing function around the arrow (if there

Re: Function name property

` reference to `function.count` outside arrows, then developers would probably always use the `in.function` version all the time and, when/if needed, have the ability to go `function.function` I know latter sounds redundant, but it completes well with the `in` meta name I personally wouldn't mind. Regards

Re: Function name property

Why do arrow functions need to reflect on themselves? I think it is more useful for all code directly inside a non-arrow function to be able to reflect on that non-arrow function. If I wrote an arrow function and then found I wanted it to reflect on itself, I'd be happier rewriting it as a

Re: Function name property

On Feb 27, 2015, at 8:00 AM, Rick Waldron wrote: I was thinking exactly this while I was reading Allen's post. Would class method definitions use `class.*`? Seems like the wrong abstraction..? Maybe all functions and method definitions use `function`, while arrows use `=` (or whatever)

Re: Function name property

Mark many framewors/libraries/younameit attach listeners at construction time, there is where everyone feels like it's cool and fast and better, and shorter to use arrow functions, then they have to mix between removable listeners and not. I personally pass objects as listeners, providing an

Re: Function name property

On Thu Feb 26 2015 at 8:22:55 PM Claude Pache claude.pa...@gmail.com wrote: Le 27 févr. 2015 à 02:04, Allen Wirfs-Brock al...@wirfs-brock.com a écrit : On Feb 26, 2015, at 3:55 PM, Mark S. Miller wrote: For most of these, my first reaction is meh. They all make sense and violate no

Re: Function name property

Rick Waldron wrote: function Component(target) { let a = function.arguments; target.on(click, event = { // In here, `arguments` refers to the `arguments` object // that was created for this invocation of Component, // which makes sense because that object has no sense of //

Re: Function name property

On Thu, Feb 26, 2015 at 11:32 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: We may have a universal way for functions to self reference themselves i post ES6. ​+1 this​ - Matthew Robb ___ es-discuss mailing list es-discuss@mozilla.org

Re: Function name property

before and discarded then I understand.) You may notice that both of the methods above have the same name, f, in spite of one lacking the lexical binding. Formerly, named functions always (barring internal var statements etc.) had lexical bindings to themselves, and the whole ES6 function name

Re: Function name property

, but if this has been discussed before and discarded then I understand.) You may notice that both of the methods above have the same name, f, in spite of one lacking the lexical binding. Formerly, named functions always (barring internal var statements etc.) had lexical bindings

Re: Function name property

On Wed, Feb 25, 2015 at 11:09 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: The automatically provided ‘name’ property of function objects has the attributes writable: false, configurable true. That means that its value can be modified using Object.defineProperty or deleted using

Re: Function name property

like concise methods *should* be a binding within themselves in a manner identical to named function expressions, but if this has been discussed before and discarded then I understand.) You may notice that both of the methods above have the same name, f, in spite of one lacking the lexical

Re: Function name property

a Map from variable name to value reflecting the lexical scope at the place it appears. More dangerously but still plausibly meta could provide an object with the above fields. The reason it is more dangerous is that passing meta might give access to a field added in a later spec. The reason

Re: Function name property

To respond to this, I searched in vain for the following message on es-discuss, only to find it in a private thread. This message helped contribute towards the syntactic direction we finally took, where allowable new meta-accesses are introduces by keyword.identifier, but only for keywords

Re: Function name property

* be a binding within themselves in a manner identical to named function expressions, but if this has been discussed before and discarded then I understand.) You may notice that both of the methods above have the same name, f, in spite of one lacking the lexical binding. Formerly, named functions

Re: Function name property

understand.) You may notice that both of the methods above have the same name, f, in spite of one lacking the lexical binding. Formerly, named functions always (barring internal var statements etc.) had lexical bindings to themselves, and the whole ES6 function name inference dealie breaks

Re: Function name property

On Thu, Feb 26, 2015 at 2:17 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: I send a new topic message about the following, but for some reason it seems slow getting to es-discuss. So, I'm trying it via a replay: Here is a new proposal for some additional meta properties that should be

Re: Function name property

in. meta.strictness could be a boolean indicating the strictness of the code it appears in. meta.environment could provide a Map from variable name to value reflecting the lexical scope at the place it appears. More dangerously but still plausibly meta could provide an object with the above fields

Re: Function name property

be a boolean indicating the strictness of the code it appears in. meta.environment could provide a Map from variable name to value reflecting the lexical scope at the place it appears. More dangerously but still plausibly meta could provide an object with the above fields. The reason it is more

Re: Function name property

On Feb 26, 2015, at 3:55 PM, Mark S. Miller wrote: But function.next -- Current yield result is awesome! Bravo. It solves a problem which is otherwise really hard to express. Actually, another possible name for this that I want to put on the table is: function.last --- the last

Re: Function name property

On Feb 26, 2015, at 3:55 PM, Mark S. Miller wrote: For most of these, my first reaction is meh. They all make sense and violate no principle, but are they worth it? I do not like the arrow function behavior. For anything named function.something occurring within an arrow function, I'd

Re: Function name property

yes, exactly. As a lexical special form, it violates no fundamental principle. On Thu, Feb 26, 2015 at 12:22 PM, Kevin Smith zenpars...@gmail.com wrote: To respond to this, I searched in vain for the following message on es-discuss, only to find it in a private thread. This message helped

Re: Function name property

Le 27 févr. 2015 à 02:04, Allen Wirfs-Brock al...@wirfs-brock.com a écrit : On Feb 26, 2015, at 3:55 PM, Mark S. Miller wrote: For most of these, my first reaction is meh. They all make sense and violate no principle, but are they worth it? I do not like the arrow function behavior.

Re: Function name property

On Feb 25, 2015, at 7:26 PM, Matthew Robb matthewwr...@gmail.com wrote: ... ​I think it would be best to put more distance between the name property of a function and it's binding​ (if any) to reduce any potential confusion. Making it a symbol property and (also my opinion) making

Re: Function name property

This doesn't address the symbol idea, but I don't see the motivation for that. A well-known symbol doesn't help usability or integrity. Matthew, could you please link to the twitter thread? Anyway, the reason 'name' is a normal property identifier and not a symbol is because it's a de-facto

Re: Efficient determination of implemented class name

, Feb 7, 2014 at 8:27 PM, Timothy Quinn tim.c.qu...@gmail.comwrote: Sweet. Thanks for the quick responses =D On Fri, Feb 7, 2014 at 11:24 PM, Erik Arvidsson erik.arvids...@gmail.com wrote: Function name is in the latest ES6 draft. On Fri Feb 07 2014 at 11:15:31 PM, Timothy Quinn tim.c.qu

Re: Efficient determination of implemented class name

On Sat, Feb 8, 2014 at 3:56 AM, Timothy Quinn tim.c.qu...@gmail.com wrote: On a related note, one can only dream that formalized OOP class definitions can be put into the ECMAScript specification so we can move away from the lack of consistency for OOP. The flexibility is really hurting the

Re: Efficient determination of implemented class name

of course if you know what you are doing and you own the whole code you can use whatever you think might work, mine was about interoperability with not always so good libraries code out there. Function name is also historically misunderstood due IE declaration VS expression bug where latter

Efficient determination of implemented class name

An area of challenge in JavaScript is the ability to detect a JavaScript objects implemented class name. I have done this in the past with some success by parsing the objects constructor but I know that this depends on the Object constructor being named and is not very efficient as it requires

RE: Efficient determination of implemented class name

o.constructor.name seems good? From: Timothy Quinnmailto:tim.c.qu...@gmail.com Sent: ‎2/‎7/‎2014 22:26 To: es-discuss@mozilla.orgmailto:es-discuss@mozilla.org Subject: Efficient determination of implemented class name An area of challenge in JavaScript

Re: Efficient determination of implemented class name

-discuss@mozilla.org Subject: Efficient determination of implemented class name An area of challenge in JavaScript is the ability to detect a JavaScript objects implemented class name. I have done this in the past with some success by parsing the objects constructor but I know

Re: Efficient determination of implemented class name

, Domenic Denicola dome...@domenicdenicola.com wrote: o.constructor.name seems good? -- From: Timothy Quinn tim.c.qu...@gmail.com Sent: 2/7/2014 22:26 To: es-discuss@mozilla.org Subject: Efficient determination of implemented class name An area of challenge

Re: Efficient determination of implemented class name

Function name is in the latest ES6 draft. On Fri Feb 07 2014 at 11:15:31 PM, Timothy Quinn tim.c.qu...@gmail.com wrote: Digging into ECMA-262, I cannot find this noted but it appears to be implemented in V8 and SpiderMonkey. Mozilla states this as non-standardhttps://developer.mozilla.org

Re: Efficient determination of implemented class name

Sweet. Thanks for the quick responses =D On Fri, Feb 7, 2014 at 11:24 PM, Erik Arvidsson erik.arvids...@gmail.comwrote: Function name is in the latest ES6 draft. On Fri Feb 07 2014 at 11:15:31 PM, Timothy Quinn tim.c.qu...@gmail.com wrote: Digging into ECMA-262, I cannot find this noted

Re: multiple modules with the same name

On Mon, Jan 27, 2014 at 11:53 PM, Marius Gundersen gunder...@gmail.com wrote: AFAIK ES-6 modules cannot be bundled (yet). But if/when they can be bundled this is an argument for silently ignoring duplicates Loader.prototype.define seems to allow bundling, by passing strings for the module

multiple modules with the same name

I didn't find anything in the spec on handling multiple modules with the same name, or how to handle the redefinition of an existing module. At any time a script type=module name=existing-nameexport default I just replaced an exsting module;/script element could be added to the dom, which would

Re: multiple modules with the same name

On Mon, Jan 27, 2014 at 1:54 PM, Marius Gundersen gunder...@gmail.com wrote: I didn't find anything in the spec on handling multiple modules with the same name [...] What should happen in such a scenario? Should existing modules be replaced? Should an error be thrown? How would that work

Re: multiple modules with the same name

On Mon, Jan 27, 2014 at 11:08 PM, Jason Orendorff jason.orendo...@gmail.com wrote: On Mon, Jan 27, 2014 at 1:54 PM, Marius Gundersen gunder...@gmail.com wrote: I didn't find anything in the spec on handling multiple modules with the same name [...] What should happen in such a scenario

Re: multiple modules with the same name

in general. Note that Jason only gave you an answer in the context of the basic module loader semantics; he didn't say what will happen in the HTML semantics. In particular, we can make it an error for there to be two definitions of the same module name in the same HTML, a la: script type

Re: multiple modules with the same name

What is the use case for allowing registration different modules under the same name? IMO should be an error. jjb On Mon, Jan 27, 2014 at 2:32 PM, David Herman dher...@mozilla.com wrote: On Jan 27, 2014, at 2:18 PM, Marius Gundersen gunder...@gmail.com wrote: So then there would be two

Re: multiple modules with the same name

...@google.com wrote: What is the use case for allowing registration different modules under the same name? IMO should be an error. jjb On Mon, Jan 27, 2014 at 2:32 PM, David Herman dher...@mozilla.com wrote: On Jan 27, 2014, at 2:18 PM, Marius Gundersen gunder...@gmail.com wrote: So

Re: multiple modules with the same name

the baby with the bathwater. Guy Bedford, based on experiences within the requirejs and commonjs worlds, has a much better solution for these scenarios. (It's also similar to how npm works). Your jQuery should depend upon the name X, but you Loader should map the name X when loaded by jQuery

Re: multiple modules with the same name

the name X, but you Loader should map the name X when loaded by jQuery to the new version in Loader.normalize(). The table of name mappings can be configured at run time. For example, if some other code depends on X@1.6 and jQuery needs X@1.7, they each load exactly the version they need because

  1   2   3   4   5   >